企业官网建设流程全解析

重新启用一个闲置很长时间的集群，从yarn组件有2个NodeManager掉线到正式解决经历了下面几个过程：
第一步，先重启，仍然掉线。
第二步，查看报错信息，数据所在磁盘使用超过90%。删除过期数据后磁盘仍占用过高。
第三步，查看文件大小，发现/tmp下生成了大量
yarn_yarn-NODEMANAGER-b9e59915a3b4ff54eb3852b58ba2fe91_pid*.hprof的文件，确定问题是OOM。
第四步，合理配置容器内存，调整NodeManager的JVM大小。从原1G调整成4G。
第五步，重启Yarn，解决问题。
整个过程中踩了几个坑，也找错过方向，所以把排查原因和解决问题过程记录下来，以备以后参考。

问题1：linux-buff/cache过大导致内存不足

1.执行 free -g 查看内存使用情况，发现内存中缓存占用太高，可用内存所剩无几。
我们可以使用下面这个文件来人工触发缓存清除的操作，Linux 提供了三种清空方式：

echo 1 > /proc/sys/vm/drop_caches # 仅清除页面缓存

echo 2 > /proc/sys/vm/drop_caches # 清除slab分配器中的对象（包括目录项和inode）

echo 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.service
cd /opt/module/dolphinscheduler/log
#停止dolphinscheduler
su dolphinscheduler
sh /opt/module/dolphinscheduler/ bin/stop-all.sh
#重启
init6

重启后buff/cache降低到了1-2，效果显著

问题2：NodeManager提示DB磁盘使用超过90%

查看数据存放磁盘路径，/yarn/nm，从hdfs上删除大部分过期数据，进入回收站/user/hive/.Trash，删除文件夹下的文件。

执行 df -h 查看磁盘占用，正常NM所在节点磁盘占用下降很多，但是掉线的2个NM节点磁盘占用仍然很高。

问题3：NM自动生成大量

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 --zone=public --list-ports
#放行端口
sudo firewall-cmd --zone=public --add-port=8042/tcp --permanent

2.查看8042是否被监听，

#查看放行端口列表
firewall-cmd --zone=public --list-ports

3.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-agent
591 sudo rm -rf /var/run/cloudera-scm-agent/process/yarn-NODEMANAGER
592 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-agent
670 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-agent
671 cd /tmp/
672 ll
673 sudo rm -rf /var/lib/cloudera-scm-agent/*
674 sudo rm -rf /var/run/cloudera-scm-agent/*
675 sudo systemctl stop cloudera-scm-agent
676 sleep 3
677 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 Unauthorized""，Agent无法通过认证连接到本地的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 verbose=self.__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数据库更新UUID
UPDATE hosts SET host_identifier = ‘abcd1234-5678-90ef-ghij-klmnopqrstuv’ WHERE name = ‘hadoop002’;
#5. 提交更改并退出

重启CM Agent。节点正常。Yarn正常。

问题5：查看supervisor日志，发现NM频繁重启退出。

cd /var/log/cloudera-scm-agent
tail -100 supervisord.log

说明NM是正常启动了，但是异常退出，结合自动生成大量
yarn_yarn-NODEMANAGER-b9e59915a3b4ff54eb3852b58ba2fe91_pid*.hprof文件，确定NM因为OOM，才导致退出和掉线。需要调整调整NM的Java 堆栈大小（字节）。

合理配置容器内存
看到配置 yarn.scheduler.maximum-allocation-mb=15360（15GB），允许单个容器申请最多15GB内存。
而NodeManager自身堆内存可能只有1-2GB，当处理大内存容器时，NodeManager自身频繁OOM，说明NodeManager分配的堆内存太小，无法处理大内存请求。这是典型的内存配置不匹配问题！
调整NodeManager 的 Java 堆栈大小（字节）为4G，保存更新，重启Yarn。