论dfs.namenode.handler.count配置参数的总要性

接早前一篇文章 一次Hadoop 奇异故障之旅 的问题说。

这篇文章的故障，虽然用分批启动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 集群服务器数量