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）

回答

相关问题