這篇文章的故障，雖然用分批啟動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 叢集伺服器數量