Nodemanager Unhealthy(exit code :143/35)

本文详细讲述了在CDH6.2.1生产环境中遇到的YARN Nodemanager健康检查异常,涉及内存溢出报警和container 143错误。通过日志分析揭示了内存溢出并非主要原因,而是exitcode:35报错导致的NM不可用,与已知问题YARN-8751相关。最终建议升级到CDH6.3.4以上版本解决该问题。

现象

CDH6.2.1版本,生产环境,通过cm页面发现yarn告警,提示Nodemanager Health Checker Bad,检查yarn前端8088页面,集群可用内存和CPU也相应减少,说明此NM失联不可用,重启NM后恢复正常。并且一个周内同一个数据NM节点出现两次这种情况。

问题定位

首先查找CM agent对NM的监控日志,进入目录:
/var/run/cloudera-scm-agent/process/*-yarn-NODEMAGER/logs/
查看stderr.log文件,发现是报的内存溢出,具体原因还要进一步定位
在这里插入图片描述
再尝试查找yarn的日志,进入目录 :
/var/log/hadoop-yarn/
查看对应日期的log文件,在日志里发现了一个问题,就是出现了大量的container报143错误,网上查了一下很多都说是内存不足。
在这里插入图片描述
一开始以为就是这个原因导致的NM不可用,但是仔细一想,这个143是container的报错,应该不会影响NM啊~
于是,去其他NM节点查看,果然也有很多143的报错,这样的话二者应该就没啥关系了。绞尽脑汁,也没查出来什么问题,只能找cloudera技术支持,怀疑是不是集群哪里配置有问题,但是NM的内存都提升到6G了,按理说够用了。
再查看NM日志,发现还有exit code:35的日志,但是这个报错有点莫名其妙,为什么会导致NM不可用更是摸不着头脑
在这里插入图片描述

结论

经过与cloudera技术人员的反复沟通,上传了一堆日志,最后得出以下几点结论:

  1. 143报错是已知的正常现象。可以看做是Log层面的小bug, 有一种误导人的倾向。已经有内部jira CDH-18221 记录这一现象:
    CDH-18221 Container exits with 143 upon success
    Resolution:Not A Bug
    总体来说整个应用是正常完成的。可以忽略这一143报错现象。
  2. NM不可用,就是因为exit code:35的报错,这是CDH6.2.1上的已知问题YARN-8751
    YARN-8751
    Container-executor permission check errors cause the NM to be marked unhealthy
    参考链接:https://issues.apache.org/jira/browse/YARN-8751
    这个问题已经在CDH 6.3.4 修复,要想解决这个bug只能升级CDH版本。。。
    参考文档:https://docs.cloudera.com/documentation/enterprise/6/release-notes/topics/rg_cdh_634_fixed_issues.html#fixed_in_6.3.4_yarn
[root@hjh01 ~]# yarn node -list 2025-07-02 19:05:04,602 INFO client.DefaultNoHARMFailoverProxyProvider: Connecting to ResourceManager at hjh01/192.168.63.101:8032 Total Nodes:3 Node-Id Node-State Node-Http-Address Number-of-Running-Containers hjh03:41086 RUNNING hjh03:8042 0 hjh02:33452 RUNNING hjh02:8042 0 hjh01:34457 RUNNING hjh01:8042 0 [root@hjh01 ~]# yarn top 2025-07-02 19:05:23,316 INFO client.DefaultNoHARMFailoverProxyProvider: Connecting to ResourceManager at hjh01/192.168.63.101:8032 YARN top - 19:06:19, up 0d, 0:26, 0 active users, queue(s): root NodeManager(s): 3 total, 3 active, 0 unhealthy, 0 decommissioned, 0 lost, 0 reb Queue(s) Applications: 0 running, 2 submitted, 0 pending, 0 completed, 0 killed Queue(s) Mem(GB): 24 available, 0 allocated, 0 pending, 0 reserved Queue(s) VCores: 24 available, 0 allocated, 0 pending, 0 reserved Queue(s) Containers: 0 allocated, 0 pending, 0 reserved q APPLICATIONID USER TYPE QUEUE PRIOR #CONT [root@hjh01 ~]# vim /usr/local/hadoop/etc/hadoop/yarn-site.xml [root@hjh01 ~]# hive which: no hbase in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/jdk/bin:/usr/local/hadoop/bin:/usr/local/hadoop/sbin:/usr/local/hive/bin:/root/bin) SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/usr/local/hive/lib/log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/usr/local/hadoop/share/hadoop/common/lib/slf4j-reload4j-1.7.36.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory] Hive Session ID = e131a6d9-ab5a-4b4c-92ef-b2ef2c57e699 Logging initialized using configuration in jar:file:/usr/local/hive/lib/hive-common-3.1.3.jar!/hive-log4j2.properties Async: true Hive-on-MR is deprecated in Hive 2 and may not be available in the future versions. Consider using a different execution engine (i.e. spark, tez) or using Hive 1.X releases. Hive Session ID = f58a189b-6fa4-4d22-9937-2b2ffd8bf3f6 hive> SET mapreduce.map.memory.mb=2048; hive> SET mapreduce.reduce.memory.mb=4096; hive> SELECT COUNT(1) FROM hjh_table LIMIT 1; FAILED: SemanticException [Error 10001]: Line 1:21 Table not found 'hjh_table' hive> SELECT > city, > COUNT(*) AS user_count, > ROUND(AVG(age), 1) AS avg_age > FROM users > GROUP BY city > ORDER BY user_count DESC; Query ID = root_20250702192000_765e8e26-cd76-45c6-b01a-5817bcfe7ff9 Total jobs = 2 Launching Job 1 out of 2 Number of reduce tasks not specified. Estimated from input data size: 1 In order to change the average load for a reducer (in bytes): set hive.exec.reducers.bytes.per.reducer=<number> In order to limit the maximum number of reducers: set hive.exec.reducers.max=<number> In order to set a constant number of reducers: set mapreduce.job.reduces=<number> Starting Job = job_1751506776899_0003, Tracking URL = http://hjh01:8088/proxy/application_1751506776899_0003/ Kill Command = /usr/local/hadoop/bin/mapred job -kill job_1751506776899_0003 Hadoop job information for Stage-1: number of mappers: 0; number of reducers: 0 2025-07-02 19:20:53,194 Stage-1 map = 0%, reduce = 0% Ended Job = job_1751506776899_0003 with errors Error during job, obtaining debugging information... FAILED: Execution Error, return code 2 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask MapReduce Jobs Launched: Stage-Stage-1: HDFS Read: 0 HDFS Write: 0 FAIL Total MapReduce CPU Time Spent: 0 msec hive>
07-04
<think> 嗯,用户遇到了YARN调度报错exitCode -1000,具体是_spark_conf_.zip文件缺失的问题。从描述看,这个文件路径在hacluster集群的.sparkStaging目录下,属于Spark提交作业时的临时配置包。用户引用了5个站内文档,其中引用[2]和[5]特别相关,都涉及.sparkStaging目录异常引发的FileNotFoundException。 用户可能是个大数据运维工程师,正在处理生产集群的故障。ta的提问非常专业,直接给出了精确的错误码和文件路径,说明已经完成初步排查。深层需求其实是想彻底解决此类问题,而不仅是临时恢复——因为引用[1]提到.sparkStaging积压导致磁盘告警,暗示这可能是反复出现的隐患。 需要重点解决两个层面:一是当前作业的急救措施,二是预防机制。急救方面,参考引用[5]的思路,应该优先检查文件是否真的被误删(HDFS回收站或手动清理),同时确认Spark配置中spark.yarn.stagingDir是否自定义过路径。预防层面则要结合引用[1]的教训:建立.sparkStaging的自动清理策略,但必须避开正在运行的作业——这点很关键,否则会引发新的-1000错误。 技术细节上想到几个关键点:首先-spark_conf_.zip是Spark动态生成的,用户无法手动重建完整文件;其次YARNexitCode -1000专指依赖文件缺失;最后hacluster集群名暗示可能是HA环境,要检查多NameNode之间的元数据同步状态。 用户提供的引用[4]关于classpath配置的内容暂时无关,但引用[3]的yarn install报错提示要注意客户端环境一致性,可以建议更新Spark版本避免已知bug。 </think> 根据报错信息和引用内容,以下是解决YARN调度报错(exitCode: -1000)的完整方案: --- ### **问题原因分析** 报错 `File does not exist: hdfs://hacluster/user/sh_shzt_tqythgl02/.sparkStaging/application_1747726663987/_spark_conf_.zip` 表明: 1. Spark提交作业时生成的临时配置文件(`_spark_conf_.zip`)在运行时被意外删除 [^1][^5] 2. `.sparkStaging` 目录因历史作业堆积导致存储压力,触发了清理操作 [^1] 3. 可能由HDFS权限问题或YARN资源管理异常引发 [^2][^4] --- ### **解决方案步骤** #### **1. 紧急恢复作业** ```bash # 手动重建缺失的临时目录(需HDFS权限) hdfs dfs -mkdir -p /user/sh_shzt_tqythgl02/.sparkStaging/application_1747726663987 # 重新提交Spark作业(追加--conf参数指定临时目录) spark-submit \ --master yarn \ --deploy-mode cluster \ --conf spark.yarn.stagingDir=hdfs://hacluster/tmp/.sparkStaging \ # 自定义临时目录 your_application.jar ``` #### **2. 清理历史残留文件** [^1] ```bash # 清理7天前的.sparkStaging目录(谨慎操作!先在测试环境验证) hdfs dfs -ls /user/hadoop/.sparkStaging | \ awk '{cmd="hdfs dfs -rm -r "$8; system(cmd)}' # 实际生产环境需过滤时间戳 ``` #### **3. 配置HDFS/YARN自动清理** 在 `yarn-site.xml` 添加配置: ```xml <property> <name>yarn.nodemanager.delete.debug-delay-sec</name> <value>600</value> <!-- 保留日志时间(秒) --> </property> <property> <name>yarn.nodemanager.localizer.cache.cleanup.interval-ms</name> <value>3600000</value> <!-- 每小时清理缓存 --> </property> ``` #### **4. 检查关键配置** 确保 `mapred-site.xml` 包含正确的classpath配置 [^4]: ```xml <property> <name>mapreduce.application.classpath</name> <value> $HADOOP_HOME/share/hadoop/common/*, $HADOOP_HOME/share/hadoop/common/lib/*, $HADOOP_HOME/share/hadoop/hdfs/*, $HADOOP_HOME/share/hadoop/yarn/*, $HADOOP_HOME/share/hadoop/yarn/lib/* </value> </property> ``` #### **5. 验证HA集群状态** 若集群为HA模式(hacluster): ```bash # 检查NameNode切换记录 grep "Failover" /var/log/hadoop-hdfs/hadoop-*-namenode-*.log # 强制同步所有NameNode元数据 hdfs dfsadmin -refreshNodes ``` --- ### **预防措施** 1. **定期清理脚本**:每周自动清理过期 `.sparkStaging` 目录(保留3天内文件) 2. **监控告警**:对HDFS关键目录(如 `/user/*/.sparkStaging`)设置容量阈值报警 3. **升级优化**:Spark 3.x+ 版本优化了临时文件管理,建议升级 [^5] > 关键点:临时目录丢失通常因清理策略与作业生命周期不匹配导致,需协调清理脚本与YARN任务保留时间(`yarn.nodemanager.delete.debug-delay-sec`)[^1][^5]。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值