CDH集群假死问题排查之后续
发布网友
发布时间：2022-09-21 04:28
共1个回答
热心网友
时间：2023-11-11 21:09
但网上查了一些资料，也有人说这是CDH版HDFS的一个bug。本身并不影响服务。考虑到CDH本身也将该异常认定为debug级别，觉得是有可能的。个人感觉这个问题除了让日志增长比较快，也就这样了。决定先把这个问题放一放。
由于疫情和工作原因，一直没功夫去看这个问题，一气之下把主节点升到16G内存，惊喜发现部署在主节点的DataNode和nodeManager几乎一直是良好状态，而从节点经常出现问题。
比如这个很可怜，除了主节点之外的nodeManager其余都挂了。
所以现在解决问题的思路无非是
1. 升级从节点的资源配置，和主节点配置保持一致。
2. 通过系统优化和调优解决问题。
本着对技术的探(mei)究(qian)之心，我决定采用第二条方案。
先把服务器上的HDFS nameNode/yarn nodeManager堆栈日志mp下来(因为这两个组件内存占用较大)，看看究竟。发现其中70%的都是不可达对象（也就是图中的灰色部分）。
于是到服务器上去一探究竟。
通过jmap 命令，发现两个现象：
1. 新生代内存比较小，并且频繁进行minor gc，几乎每分钟都有。
2. 老年代内存一直在增长并且没有释放的迹象。
感觉新生代内存过小可能会导致：
1. 频繁的minor gc，很多新生对象没有经过充分gc而进入老年代。（比如新生对象存活时间是五分钟，而频繁的minor gc导致3分钟这个对象就被当成老人放入老年代）
2. 频繁的minor gc，可能导致对cpu资源的争夺或其它未知的原因导致nodeManager或者dataNode不良。
而老年代内存回收过慢则导致系统内存一直处于高位。
于是尝试设置两个参数：
-XX:NewRatio=2 -XX:CMSInitiatingOccupancyFraction=45
第一个XX:NewRatio是指扩大新生代内存的比例，降低minor gc的频率，而第二个则是降低触发老年代full gc内存回收的阈值，使得老年代不至于保存大量已不可达的对象。如果但这个值如果设太低，则又会频繁触发full gc和major gc，所以也不敢设置太低，设成45。
通过设置，HDFS的dataNode连接不良的问题得以解决，但yarn的nodeManager还是频繁出现不良。
继续百度+谷歌，发现JDK1.8有更好的垃圾收集器，G1回收器，感兴趣的同学请移步：
深入理解JVM（5）——GC垃圾回收（3）——8大垃圾收集器
G1回收器比之前用的新生代并行垃圾收集器无论是吞吐量优先(让单位时间内，STW 的时间最短)还是对响应时间优先(尽可能让单次 STW 的时间最短)的处理都比并行垃圾处理器(useParNewGC）优雅不少。
我们可以通过以下参数设置，其中XX:MaxGCPauseMillis为单次最大gc停顿时间。这是一个软目标，G1会尽量保证单次停顿低于该值。
-XX:+UseG1GC -XX:MaxGCPauseMillis=200
设置完之后，集群稳定的一批。跑了一些任务，也没有问题。收工。
最后又是安利追剧时间，今天安利的是精英律师，老干部嘴皮子简直6得不行了，栗娜真的超好看。
