一次Hadoop 奇异故障之旅

中午接到一个同事的消息，说一个有200多个dn节点的集群（CDH）hive没办法创建分区了。重启了多次，都没有效果。后来发现namenode也一直出现故障。

收到消息，就联机上去看了一下，果然hive的命令全部都挂起来了，hadoop fs 命令也一样被挂起。在CDH 的管理界面上检查了一下NN节点的状态，发现NN有问题。因为是生产环境，已经有半天没有数据上报了。运维的同事都比较着急。

没办法，先来常规吧，重启HDFS服务，等了10多分钟，NN状态正常了两分钟，又挂掉。几次下来，放弃了这个方法。仔细研究了一下这个集群，200多个dn节点，NN HA，数据量已经存到了3个PB。正常情况下每秒入库数据量可以达到400-500M/s。这时想到看一下NN 元数据吧，发现达到惊人的300G。第一个想法是NN 的JVM设置，那就加大吧，最后失望，因为加多少启动NN的时候就能吃多少，最后到350G 也能全部吃完。

再回来翻查NN的日志，每次会有3-5分钟的停顿，不知道在做什么，也没有写日志，但是NN进程一直在占用CPU，所以就在高级配置里加上了GC输出的参数，查看在NN启动的时候，GC的情况。这时候看到了问题，NN启动JVM的内存占用飞速上升，直到占满，然后重启，所以十几分钟一次的自动重启就是这么来的了。

直到了他为什么重启，但是还是要去找到解决方法的，又去翻了一下NN启动的流程文档，了解了，在NN启动的时候，各个DN会讲自己本地的文件块信息上报给NN，现在有200台DN，而且每个DN上的文件块数量也是相当的庞大，同时上报的时候，NN的内存就不够用了。最终找到一个解决方法，分批次启动DN，
步骤：1.启动NN,JN,Failovercontrol
2.待NN完全启动，并且日志提示是要等待DN上报消息的时候，开始分40台一批，启动DN节点。

经过以上操作后，整个集群的HDFS服务终于恢复了。

不过这只是恢复了，之前的发生故障的原因回溯另外有时间在写一篇文章来说把。