中午接到一个同事的消息，说一个有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服务终于恢复了。
虽然用分批启动DN节点的方法，避免了重启HDFS的出现的内存问题。但是治标不治本，风险依然是存在的。所以要从根本上根治这个疑难杂症，就要从其他参数配置着手。
最终，锁定一个参数配置dfs.namenode.handler.count。先来看看它的解释
*NameNode有一个工作线程池用来处理客户端的远程过程调用及集群守护进程的调用。处理程序数量越多意味着要更大的池来处理来自不同DataNode的并发心跳以及客户端并发的元数据操作。对于大集群或者有大量客户端的集群来说，通常需要增大参数dfs.namenode.handler.count的默认值10。设置该值的一般原则是将其设置为集群大小的自然对数乘以20，即20logN，N为集群大小。
如果该值设的太小，明显的状况就是DataNode在连接NameNode的时候总是超时或者连接被拒绝，但NameNode的远程过程调用队列很大时，远程过程调用延时就会加大。症状之间是相互影响的，很难说修改dfs.namenode.handler.count就能解决问题，但是在查找故障时，检查一下该值的设置是必要的。*
我们发现，在集群中，这个参数被本地的维护人员修改的很大，达到了4000，也就是说，配置了一个线程池，可以容纳4000个线程，这样在消息通信时，这里容纳的信息量就是非常庞大的，最终造成了内存的溢出。因此这个值可以放大，但是不能加的过大。配多少？有公式
python -c 'import math ; print int(math.log(N) * 20)'
#N 集群服务器数量