namenode 問題小記

問題1:namenode進程故障

Namenode掛掉，Namenode gc日誌裏面YGC報錯promotion failed

現象描述

NameNode進程掛掉，Namenode gc日誌裏面YGC報錯promotion failed。

可能緣由

Young gc的時候，須要複製eden區和from區內的對象到to區，若是此時to區滿了，就會使用悲觀策略複製到old區，而此時old區也滿了，就會報promotion failed。

定位思路

1. GC參數設置不合理
2. 進程內存分配過少

處理方式

方式1：

1. 對於第三方管理的JVM，調低-XX:XXInitiatingOccupancyFraction值，下降觸發NN XX GC的百分比，保證old區有足夠內存。

方式2：

1.擴大NN內存。

問題2:NameNode內存FULL GC問題處理

生產集羣namenode Full GC 告警頻繁

問題描述：

將standby namenode（nn1）的內存擴至80GB後，切換namenode，standby namenode在轉換爲active狀態時進程死掉，查看namenode和zkfc日誌發現：

standby namenode由standby轉換爲active時，出現socket timeout，致使namenode狀態轉爲SERVICE_NOT_RESPONDING，切換失敗。

緣由

bdp生產集羣文件數量達到1.9億，namenode當前內存64G，已使用約57G，內存不足，GC嚴重

處理

主機內存共128G，當前namenode內存爲64GB，除namenode，resourcemanager，ZK，journalnode，ZKFC等進程已分配的內存外，剩餘總內存約40G。

1. 修改namenode JVM內存參數，將內存由64GB改成90GB，並分發;
2. 檢查當前active namenode爲nn2;
3. 重啓standby namenode (nn1),肯定已修改的參數已生效;
4. 經過命令「hdfs haadmin -failover nn2 nn1」將active namenode切換至nn1;
5. 待nn1爲active,肯定日誌正常，且正常提供服務後，重啓nn2 namenode
6. 肯定nn2 UI頁面及日誌正常，及已修改的參數已生效。

可選優化方向

1. 文件數量達到1.9億，致使namenode元數據量過大，可合併小文件以減小namenode內存使用，避免Full GC。
2. 在core-site.xml文件中修改ha.health-monitor.rpc-timeout.ms參數值，來擴大zkfc監控檢查超時時間。