YARN掉线解决过程

📅 2026/6/17 9:53:11
YARN掉线解决过程
YARN掉线解决过程问题1linux-buff/cache过大导致内存不足问题2NodeManager提示DB磁盘使用超过90%问题3NM自动生成大量问题4查看NM日志、Yarn日志、supervisor日志。这个过程踩了太的坑问题5查看supervisor日志发现NM频繁重启退出。重新启用一个闲置很长时间的集群从yarn组件有2个NodeManager掉线到正式解决经历了下面几个过程第一步先重启仍然掉线。第二步查看报错信息数据所在磁盘使用超过90%。删除过期数据后磁盘仍占用过高。第三步查看文件大小发现/tmp下生成了大量yarn_yarn-NODEMANAGER-b9e59915a3b4ff54eb3852b58ba2fe91_pid*.hprof的文件确定问题是OOM。第四步合理配置容器内存调整NodeManager的JVM大小。从原1G调整成4G。第五步重启Yarn解决问题。整个过程中踩了几个坑也找错过方向所以把排查原因和解决问题过程记录下来以备以后参考。问题1linux-buff/cache过大导致内存不足1.执行 free -g 查看内存使用情况发现内存中缓存占用太高可用内存所剩无几。我们可以使用下面这个文件来人工触发缓存清除的操作Linux 提供了三种清空方式echo 1 /proc/sys/vm/drop_caches # 仅清除页面缓存echo 2 /proc/sys/vm/drop_caches # 清除slab分配器中的对象包括目录项和inodeecho 3 /proc/sys/vm/drop_caches # 清除page cache和slab分配器中的对象包括目录项以及inode执行后buff/cache确实下降了但是重启任务又会上升。** 2.重启机器**前提是集群没在正式使用并且有5-6年没有重启过。暂停集群上所有应用#停止mysql:systemctl stop mysql#停止CDH:/bin/systemctl stop cloudera-scm-server.service/bin/systemctl stop cloudera-scm-agent.servicecd /opt/module/dolphinscheduler/log#停止dolphinschedulersu dolphinschedulersh /opt/module/dolphinscheduler/ bin/stop-all.sh#重启init6重启后buff/cache降低到了1-2效果显著问题2NodeManager提示DB磁盘使用超过90%查看数据存放磁盘路径/yarn/nm从hdfs上删除大部分过期数据进入回收站/user/hive/.Trash删除文件夹下的文件。执行 df -h 查看磁盘占用正常NM所在节点磁盘占用下降很多但是掉线的2个NM节点磁盘占用仍然很高。问题3NM自动生成大量yarn_yarn-NODEMANAGER-b9e59915a3b4ff54eb3852b58ba2fe91_pid*.hprof文件删完hdfs数据第2天没有跑任何采集计算任务的情况掉线的2个节点磁盘占用竟然升高了在掉线节点服务器上查看具体文件大小挨个文件执行 du -sh filepath ,和正常节点文件夹做对比。发现掉线节点的 /tmp文件超级大包涵大量yarn_yarn-NODEMANAGER-b9e59915a3b4ff54eb3852b58ba2fe91_pid*.hprof文件查了下是OOM此刻我还没意识到OOM是导致NM掉线的原因只是删除了这些文件问题4查看NM日志、Yarn日志、supervisor日志。这个过程踩了太的坑坑一翻NM日志发现报错http://10.2.0.242:8042/jmx访问不到。1.开放8042端口#查看放行端口列表firewall-cmd --zonepublic --list-ports#放行端口sudo firewall-cmd --zonepublic --add-port8042/tcp --permanent2.查看8042是否被监听#查看放行端口列表firewall-cmd --zonepublic --list-ports3.Jps发现NM运行端口是7733查找执行yarn的配置文件/var/run/cloudera-scm-agent/process/5184-yarn-NODEMANAGER/yarn-site.xml端口确实是8842.坑二轻信某AI软件删除了部分文件节点掉线了。/var/run/cloudera-scm-agent/process/下的文件是NM启动时动态生成的如果有问题删除重启强制生成正确版本。删除了以下文件590 sudo systemctl stop cloudera-scm-agent591 sudo rm -rf /var/run/cloudera-scm-agent/process/yarn-NODEMANAGER592 sudo rm -rf /var/lib/cloudera-scm-agent/*593 sudo rm -rf /var/lib/hadoop-yarn/yarn-nm-recovery/*594 sudo systemctl start cloudera-scm-agent670 sudo tar -czf /tmp/cm-agent-backup-$(date %Y%m%d).tar.gz /var/lib/cloudera-scm-agent /var/run/cloudera-scm-agent /etc/cloudera-scm-agent671 cd /tmp/672 ll673 sudo rm -rf /var/lib/cloudera-scm-agent/*674 sudo rm -rf /var/run/cloudera-scm-agent/*675 sudo systemctl stop cloudera-scm-agent676 sleep 3677 sudo pkill -9 -f “supervisord”678 sudo pkill -9 -f “cmf-agent”679 sudo pkill -9 -f “python.*cmf”680 ps aux | grep -E “supervisord|cmf-agent” | grep -v grep删除完节点直接报错掉线了。恢复了/var/run/cloudera-scm-agent/process/下除了yarn-NODEMANAGER之外的文件没有恢复yarn-NODEMANAGER是因为没有备份删除前一定要做好备份恢复完还是报错CDH Agent启动失败的主要原因是ProtocolError for 127.0.0.1/RPC2: 401 UnauthorizedAgent无法通过认证连接到本地的supervisor进程这通常是由于supervisor的认证配置问题。[[11/Dec/2025 16:40:04 0000] 23674 MainThread supervisor INFO Trying to connect to supervisor (Attempt 1) [11/Dec/2025 16:40:04 0000] 23674 MainThread supervisor ERROR Failed! trying again in 2 second(s): ProtocolError for 127.0.0.1/RPC2: 401 Unauthorized Traceback (most recent call last): File “/opt/cloudera/cm-agent/lib/python2.7/site-packages/cmf/supervisor.py”, line 127, in connect obj cls(cfg, os_ops_obj) File “/opt/cloudera/cm-agent/lib/python2.7/site-packages/cmf/supervisor.py”, line 87, ininitself.identifier self.__get_supervisor_identification() File “/opt/cloudera/cm-agent/lib/python2.7/site-packages/cmf/util/init.py”, line 531, in new_fn return fn(self, *args, **kwargs) File “/opt/cloudera/cm-agent/lib/python2.7/site-packages/cmf/supervisor.py”, line 365, in __get_supervisor_identification return self.client.supervisor.getIdentification() File “/usr/lib64/python2.7/xmlrpclib.py”, line 1233, incallreturn self.__send(self.__name, args) File “/usr/lib64/python2.7/xmlrpclib.py”, line 1591, in __request verboseself.__verbose File “/opt/cloudera/cm-agent/lib/python2.7/site-packages/supervisor/xmlrpc.py”, line 470, in request ‘’ ) ProtocolError: ProtocolError for 127.0.0.1/RPC2: 401 Unauthorized此刻AI建议我删除XX,重新配置CM Agent.果断放弃。自己查了下强制停止了supervisor进程又重启。supervisor认证通过了。但节点还是掉线。最后的尝试停止CM agent服务强制停止supervisor进程重启CM agent服务 日志报错“ERROR avro-servlet-hb-processor-11:com.cloudera.server.cmf.AgentProtocolImpl: Host validation failed for hadoop002. Host’s uuid does not match with the known uuid of 128aa966-171d-4be8-bf69-db73ccbe71ff.”节点的 /var/lib/cloudera-scm-agent/uuid 文件中的UUID与CM Server数据库中的记录不一致。登录到CM Server数据库#2. 查询当前节点信息SELECT host_id, name, ip_address, host_identifier FROM hosts WHERE name ‘hadoop002’;#3. 获取节点2的实际UUID登录hadoop002#在 hadoop002 上执行cat /var/lib/cloudera-scm-agent/uuid#假设输出abcd1234-5678-90ef-ghij-klmnopqrstuv#4. 在CM Server数据库更新UUIDUPDATE hosts SET host_identifier ‘abcd1234-5678-90ef-ghij-klmnopqrstuv’ WHERE name ‘hadoop002’;#5. 提交更改并退出重启CM Agent。节点正常。Yarn正常。问题5查看supervisor日志发现NM频繁重启退出。cd /var/log/cloudera-scm-agenttail -100 supervisord.log说明NM是正常启动了但是异常退出结合自动生成大量yarn_yarn-NODEMANAGER-b9e59915a3b4ff54eb3852b58ba2fe91_pid*.hprof文件确定NM因为OOM才导致退出和掉线。需要调整调整NM的Java 堆栈大小字节。合理配置容器内存看到配置 yarn.scheduler.maximum-allocation-mb1536015GB允许单个容器申请最多15GB内存。而NodeManager自身堆内存可能只有1-2GB当处理大内存容器时NodeManager自身频繁OOM说明NodeManager分配的堆内存太小无法处理大内存请求。这是典型的内存配置不匹配问题调整NodeManager 的 Java 堆栈大小字节为4G保存更新重启Yarn。