Hadoop DataNode內存消耗和GC行爲

最近我們遇到了與我們的集羣（CDH 5.3.1）相關的問題，這些問題表現在NameNode以及DataNode在長GC循環中表現出來，從30秒到最高几分鐘。Hadoop DataNode內存消耗和GC行爲

JVM設置仍然是默認設置，但考慮到我們的集羣已經增長到3400萬塊，這種行爲是可以解釋的。

對於NN，對GC設置（例如年輕gen size，survivorratio）的heapsize和其他小調整的簡單調整已經讓我們再次預測到了短暫的GC暫停。

對於DN，我們仍然遭受週期性的長GC停頓。我觀察到的是，特別長的GC暫停每6小時發生一次（Full GC）。現在我假設Cloudera爲塊報告間隔dfs.blockreport.intervalMsec設置6小時的默認值是對這種模式的貢獻。

我想了解的是，如果有建議我如何解決這個問題，我需要找到GC設置，這兩個設置都能滿足正常操作內存分配（似乎大部分都是好的）以及快速分配我每隔6小時看幾分鐘。

的DN服務器有256G RAM & 20個物理內核

這是Java的熱點jdk1.7.0_67。

我現在的，最理想的設置是：

-server 
-Xmn5g 
-Xms12884901888 
-Xmx12884901888 
-XX:SurvivorRatio=3 
-XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC 
-XX:+CMSConcurrentMTEnabled 
-XX:CMSInitiatingOccupancyFraction=60 
-XX:+CMSParallelRemarkEnabled 
-XX:+UseCMSInitiatingOccupancyOnly 
-XX:+ScavengeBeforeFullGC 
-XX:+CMSScavengeBeforeRemark 
-XX:MaxTenuringThreshold=15

我也很想聽到的，如果不是調整的JVM也有辦法影響blockreport不那麼激進？

見GC日誌的時間範圍內的問題： http://hastebin.com/zafabohowi

來源

2015-05-28 bfloriang

您應該啓用時間戳記的GC日誌記錄（'-XX：+ PrintGCTimeStamps -XX：+ PrintGCDetails'）並附上覆蓋有問題範圍的日誌。 CMS完整的GC是你想要避免的，因爲它們是單線程的，因此非常慢，所以它的原因將是有趣的。請參閱日誌的鏈接 – the8472

@ the8472。它有一個25.76秒特別昂貴的GC實例。 – bfloriang

這看起來像是一個單線程（實時==用戶時間）舊版本的集合，但我認爲它應該打印一些類似於「併發模式失敗」的東西。嘗試在其上添加更多診斷標誌，或許他們會提供一些見解：'-XX：PrintCMSStatistics = 1 -XX：PrintFLSStatistics = 1 -XX：+ PrintHeapAtGC -XX：+ PrintPromotionFailure'。也許hadoop塊報告做了一個非常大的分配，不適合年輕人或經歷由於分裂造成的升級失敗？ – the8472

好，通過GCViewer運行日誌它只是好像有活性的（例如，啓動17:09）一陣，填補了老一代直到它導致一些失敗（在17:15）。

只需嘗試顛倒堆大小，讓它有更多的呼吸空間，直到任務完成。

超出併發模式故障似乎仍有一些相對較長的暫停，請嘗試應用these options以查看它們是否可以削減幾毫秒。

來源

2015-06-03 11:49:53 the8472

是的，縮小這個年輕的gen也會爲那些長期運行的任務在老一代留下更多的空間，也就是說它給了老物件更多的呼吸空間 – the8472

Hadoop DataNode內存消耗和GC行爲

回答

相關問題