Hadoop 3.3.1中MapReduce任务卡在map 0% reduce 0%问题排查求助

从你描述的Hadoop 3.3.1环境下的问题来看，任务卡在初始进度但所有组件都显示RUNNING，结合你提供的配置和状态信息，我整理了几个核心排查方向和可能原因：

一、资源分配异常的排查 #

你提到任务仅分配了1个容器，这大概率和资源调度有关：

• 检查节点可用资源：执行yarn node -list -all查看所有NodeManager的可用CPU核数和内存，确认是否有足够资源分配给Map任务。如果你的NodeManager配置了8核，但集群其他任务已占满资源，或单个Map任务请求的核数/内存过高，都会导致新的Map容器无法分配。
• 核查Map任务资源请求配置：查看mapred-site.xml中的mapreduce.map.memory.mb和mapreduce.map.cpu.vcores参数，确认这些请求值是否在NodeManager的资源范围内（比如你的NM配置了8核，单个Map任务请求核数不能超过8，同时要留足AM的资源）。
• 检查队列资源限制：如果使用Capacity Scheduler，检查yarn-site.xml中default队列的资源配额（比如yarn.scheduler.capacity.root.default.capacity），确认队列是否还有剩余资源分配给新任务。

二、自定义文件系统（madfs）的潜在问题 #

你的yarn-site.xml中配置了自定义文件系统madfs，这很可能是任务卡住的核心原因：

• 验证文件系统可用性：先执行hadoop fs -ls wordcount/input测试是否能正常访问输入文件，如果这个命令卡顿或报错，说明自定义文件系统存在连接、权限或兼容性问题，导致Map任务无法读取数据，进而卡在0%进度。
• 查看Application Master（AM）日志：通过任务的Tracking-URL（比如你提供的http://master:45299）进入AM的监控页面，查看AM的日志详情，看是否在尝试与madfs交互时出现阻塞或未捕获的异常。

三、容器启动与初始化问题 #

即使容器显示RUNNING，也可能存在启动失败或初始化卡住的情况：

• 检查NodeManager上的容器日志：到每个NodeManager的$HADOOP_HOME/logs/userlogs目录下，找到对应applicationId的子目录，查看Map容器的stdout和stderr日志，这里通常会记录容器启动时的依赖加载、权限问题等细节。
• 确认HADOOP_MAPRED_HOME配置一致性：你的mapred-site.xml中配置了HADOOP_MAPRED_HOME，要确保集群所有节点（Master和Slave）的这个路径完全一致，且该目录对运行Hadoop的用户（xyz）有读写权限，否则容器无法加载MapReduce的核心依赖。

四、其他补充排查步骤 #

• 直接查看实时日志：由于你的日志聚合是DISABLED状态，直接到NodeManager的userlogs目录下找对应任务的日志是最直接的方式，能看到最实时的报错信息。
• 收集完整任务日志：执行yarn logs -applicationId <你的appId>，这个命令会自动收集所有节点上该任务的日志，方便统一排查。
• 检查系统资源状态：查看集群各节点的CPU、内存、磁盘IO使用率，比如磁盘IO过高会导致文件读取缓慢，进而让任务看起来卡住；内存不足也可能导致容器无法正常初始化。

内容的提问来源于stack exchange，提问作者Jingjia Luo