中午接到一個同事的消息，說一個有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 集羣服務器數量