cdh安装对计算机内存 等硬件有要求么

1. 实验环境：Mac下VMware虚拟机

2. *** 作系统：CentOS 6.5 x64 (至少内存2G以上，这里内存不够的同学建议还是整几台真机配置比较好，将CDH的所有组件全部安装会占用很多内存，我已开始设置的虚拟机内存是1G，安装过程中直接卡死了)

3. Cloudera Manager：5.1.3

4. CDH: 5.1.3

这个问题早在去年9月就被发现了，但是现场保存得不好，只在上留了几张截图。并且笔者那时跑到11区浪去了，当时也被有司请去喝了一段时间的茶，因此细节没有保留太多，权当留个备忘吧。

故障现象：

凭直觉确定是OOM了。去/var/log/cloudera-scm-firehose目录下查看Service Monitor的角色日志，果然有频繁的因JVM GC导致的stop-the-world。

于是我们将Service Monitor的堆内内存和堆外内存都加大到16GB，重启之，发现完全没有好转。

接下来自然是采用top+ps+jstack大法，试图定位到出问题的线程，但令人窒息的是，吃CPU最狠的那个线程竟然没有线程ID。忘了截图，就这样吧。

翻看CDH官方文档，找到了其监控服务中的数据存储相关细节，传送门 https://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_storage.html 。简单概括如下。

下图示出Cloudera Manager提供的监控图表展开后的数据粒度选项。

由于时序数据肯定会占绝大部分（最小都要有10GB大），联想到rollup可能容易出现问题。从日志看，rollup的延迟已经达到了一天之多，说明进入到LevelDB的监控数据过多，处理不过来了。这是造成内存爆掉的真正原因。

在CDH 6.x版本中，可以通过将 firehose.timeseries.rollup.disabled 配置项设为false来禁用指标rollup，但是同时会造成汇总粒度只剩下raw，查看起来不是很方便。更合适的方法是禁用掉一些产生大量指标但平时又不太关心的服务的监控，即在对应服务的配置中取消勾选“Enable Metric Allocation”一项。

通过观察每个服务的Charts Library，发现Kudu的监控指标和实体都很多（每张表都会产生监控数据）。我们关闭对Kudu的监控，并手动清理了 firehose.storage.base.directory 目录内的监控数据后，再重启Service Monitor，一切正常。

民那晚安，祝身体健康，百毒不侵。

两个月前写过一篇文章，HDFS和Yarn经常出现dataNode和NameNode之间, nodeManager与resourceManager之间 连接不良的现象，开始怀疑是service Monitor监控内存失败的问题，于是更换了JDK版本，当时认为问题解决，然而没过多久，假死和连接不良现象又出现了。重新将nameNode日志阈值改成debug，发现依然存在如下异常：

但网上查了一些资料，也有人说这是CDH版HDFS的一个bug。本身并不影响服务。考虑到CDH本身也将该异常认定为debug级别，觉得是有可能的。个人感觉这个问题除了让日志增长比较快，也就这样了。决定先把这个问题放一放。

由于疫情和工作原因，一直没功夫去看这个问题，一气之下把主节点升到16G内存，惊喜发现部署在主节点的DataNode和nodeManager几乎一直是良好状态，而从节点经常出现问题。

比如这个很可怜，除了主节点之外的nodeManager其余都挂了。

所以现在解决问题的思路无非是

1. 升级从节点的资源配置，和主节点配置保持一致。

2. 通过系统优化和调优解决问题。

本着对技术的探(mei)究(qian)之心，我决定采用第二条方案。

先把服务器上的HDFS nameNode/yarn nodeManager堆栈日志dump下来(因为这两个组件内存占用较大)，看看究竟。发现其中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得不行了，栗娜真的超好看。

---