Cassandra和G1垃圾收集器停止世界事件（STW）

我們有一個6節點Cassandra集羣正在大量使用。我們一直在使用垃圾收集器停止世界事件，在節點中可能需要長達50秒的時間，同時Cassandra節點沒有響應，甚至不接受新的登錄。Cassandra和G1垃圾收集器停止世界事件（STW）

額外的細節：

卡桑德拉版本：3.11
堆大小= 12 GB
我們使用G1垃圾收集器的默認設置
節點尺寸：4級的CPU 28 GB RAM
G1 GC行爲在所有節點上都是相同的。

任何幫助將非常感謝！

編輯1：

檢查對象創建統計信息時，它看起來並不健康。

編輯2：

我試圖通過克里斯Lohfink使用建議的設置，這裏是GC報告：

使用CMS建議的設置 http://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMTcvMTAvOC8tLWdjLmxvZy4wLmN1cnJlbnQtLTE5LTAtNDk=

使用G1建議的設置 http://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMTcvMTAvOC8tLWdjLmxvZy4wLmN1cnJlbnQtLTE5LTExLTE3

行爲保持基本一致：

老根開始填滿。
如果沒有完整的GC和STW事件，GC無法正確清理。
完整的GC開始花費更長時間，直到節點完全沒有響應。

我將獲得最大分區大小的cfstats輸出和每讀取最快分區的墓碑，並再次編輯帖子。

來源

2017-10-04 Scudeler

GC在增加後出現堆，所以無論您的應用程序是否只需要更多的內存，您有泄漏或cassandra的配置方式會以G1無法跟上的方式突發分配。這些案件無法單獨與這些圖表區分開來。 – the8472

什麼是您當前的GC設置？ –

您可以包含您的cfstats輸出以獲取最大分區大小和每次讀取的墓碑嗎？掃描墓碑並反序列化大分區索引是高客觀分配率的常見原因。如果在不知道當前設置的情況下如何提高您的GC值 –

不知道你的現有設置或可能的數據模型問題，一些保守的設置繼承人的猜測用來儘量減少撤離不夠不必空間暫停（檢查GC日誌）：

-Xmx12G -Xms12G -XX:+UseG1GC -XX:G1ReservePercent=25 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:MaxGCPauseMillis=500 -XX:-ReduceInitialCardMarks -XX:G1HeapRegionSize=32m

這也應該有助於減少更新的暫停記住集合，這將成爲一個問題，並減少可能成爲問題的大型對象，這取決於數據模型。 確保-Xmn未設置爲。

12Gb與C *可能更適合使用CMS的價值，你可以得到更好的吞吐量。只需要小心隨着時間的推移，可以分配相當大的對象的碎片。

-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=55 -XX:MaxTenuringThreshold=3 -Xmx12G -Xms12G -Xmn3G -XX:+CMSEdenChunksRecordAlways -XX:+CMSParallelInitialMarkEnabled -XX:+CMSParallelRemarkEnabled -XX:CMSWaitDuration=10000 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCondCardMark

最有可能的問題是數據模型問題或您的供應不足。

來源

2017-10-04 19:32:26

你看過使用Zing嗎？像這樣的Cassandra情況是一個典型的用例，因爲Zing從根本上消除了Cassandra節點和集羣中所有與GC相關的故障。

您可以在JavaOne（https://www.slideshare.net/howarddgreen/understanding-gc-javaone-2017）最近的「Understanding GC」對話中看到關於如何/爲什麼的一些詳細信息。或者直接跳到幻燈片56-60以獲取Cassandra的具體結果。

來源

2017-10-06 01:55:04

Cassandra和G1垃圾收集器停止世界事件（STW）

回答

相關問題