Cassandra 特定节点上的大量 GC
Cassandra lots of GC on specific nodes
自从我们将 cassandra 集群从版本 2.0.17 升级到 2.1.15 后，我们遇到了 3 节点集群中的 2 个节点的问题。
他们一直比另一个 cpu 使用更多。更仔细的调查似乎表明它取决于 GC - 当我使用 jstat -gc 跟踪所有 3 个 cassandra 进程时，我可以看到节点 1 和 3 的 GC 频率比节点 2 高得多。
这也从 cassandra 日志中显示出来，除此之外，GC 似乎还很慢：
INFO [Service Thread] 2017-07-31 16:17:35,655 GCInspector.java:258 - ParNew GC in 210ms. CMS Old Gen: 562659176 -> 612323584; Par Eden Space: 411959296 -> 0; Par Survivor Space: 49544256 -> 51445760
INFO [Service Thread] 2017-07-31 16:17:41,694 GCInspector.java:258 - ParNew GC in 525ms. CMS Old Gen: 612323584 -> 764506632; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:17:48,702 GCInspector.java:258 - ParNew GC in 334ms. CMS Old Gen: 823507232 -> 907859304; Par Eden Space: 411959296 -> 0; Par Survivor Space: 39578752 -> 51445760
INFO [Service Thread] 2017-07-31 16:17:58,667 GCInspector.java:258 - ParNew GC in 369ms. CMS Old Gen: 907859304 -> 1006118696; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:18:08,766 GCInspector.java:258 - ParNew GC in 456ms. CMS Old Gen: 1006118696 -> 1123833216; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:18:16,979 GCInspector.java:258 - ParNew GC in 540ms. CMS Old Gen: 1123833216 -> 1286209400; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:18:22,833 GCInspector.java:258 - ParNew GC in 386ms. CMS Old Gen: 1286209400 -> 1395049184; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:18:41,111 GCInspector.java:258 - ParNew GC in 201ms. CMS Old Gen: 801910056 -> 895733880; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:18:43,134 GCInspector.java:258 - ParNew GC in 221ms. CMS Old Gen: 895733880 -> 975905560; Par Eden Space: 411624624 -> 0;
INFO [Service Thread] 2017-07-31 16:19:22,733 GCInspector.java:258 - ParNew GC in 214ms. CMS Old Gen: 1030387520 -> 1079340184; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:19:31,430 GCInspector.java:258 - ParNew GC in 266ms. CMS Old Gen: 1079340184 -> 1166678176; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:19:35,061 GCInspector.java:258 - ParNew GC in 606ms. CMS Old Gen: 1166678176 -> 1353067264; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:19:37,808 GCInspector.java:258 - ConcurrentMarkSweep GC in 2249ms. CMS Old Gen: 1353067264 -> 477397536; Par Eden Space: 411936152 -> 0; Par Survivor Space: 51445760 -> 0
INFO [Service Thread] 2017-07-31 16:19:48,769 GCInspector.java:258 - ParNew GC in 362ms. CMS Old Gen: 695828520 -> 793426632; Par Eden Space: 411959296 -> 0; Par Survivor Space: 40276928 -> 51445760
INFO [Service Thread] 2017-07-31 16:19:58,710 GCInspector.java:258 - ParNew GC in 376ms. CMS Old Gen: 793426632 -> 899121400; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:20:23,431 GCInspector.java:258 - ParNew GC in 225ms. CMS Old Gen: 1067967744 -> 1139648600; Par Eden Space: 411629080 -> 0; Par Survivor Space: 40055056 -> 51445760
INFO [Service Thread] 2017-07-31 16:20:24,988 GCInspector.java:258 - ParNew GC in 210ms. CMS Old Gen: 1161527408 -> 1226340808; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:20:27,596 GCInspector.java:258 - ConcurrentMarkSweep GC in 236ms. CMS Old Gen: 1161527408 -> 477824664; Par Eden Space: 325760 -> 56800072;
INFO [Service Thread] 2017-07-31 16:21:24,879 GCInspector.java:258 - ParNew GC in 574ms. CMS Old Gen: 705116088 -> 868474072; Par Eden Space: 411959296 -> 0;
将 max heap 和 new heap 从 1966M 和 491M 分别增加到 2500M 和 1024M 似乎影响不大。值一一调整，中间 nodetool drain 和 cassandra 服务重启。
我也试过减轻这个集群的所有负载，这确实对 cassandra cpu 的使用有影响 - 但节点 1 和 3 继续使用更多 cpu。
更高的 cpu 使用率不是恒定的 - 它在 'normal' 和高之间来回波动，这似乎与 GC 运行相关。
我无法确定可能的原因以及如何进一步调查。非常感谢任何想法。
2.5gb 的堆对于 C* 实例来说小得离谱。不要期望任何低于 8gb 的东西在没有大量 GC 的情况下做很多工作，它根本不是为此设计的。考虑到每 5-10 秒左右的 200-500 毫秒 gc，所有事情都非常好。
见 http://docs.datastax.com/en/landing_page/doc/landing_page/planning/planningHardware.html#planningHardware__memory
For both dedicated hardware and virtual environments, the recommended memory is:
Production 32 GB to 512 GB; the minimum is 8 GB for Cassandra nodes.
Development in non-loading testing environments: no less than 4 GB.
Heap size is usually between ¼ and ½ of system memory.
Cassandra automatically calculates the maximum heap size (MAX_HEAP_SIZE) based on this formula: max(min(1/2 ram, 1024MB), min(1/4 ram, 8GB)
The recommended maximum heap size depends on which GC is used:
Older computers Typically 8 GB.
CMS for newer computers (8+ cores) with up to 256 GB RAM No more 14 GB.
通常，当您查看您认为是 cassandra 问题的问题时，结果证明这是我们自己的错。我们在一个过程中有一个错误，导致它不断地创建、查询和删除单个特定键的记录。这意味着它正在创建大量的墓碑，并且查询正在命中越来越多的墓碑。复制因子也设置为 2，解释了为什么它只影响 3 个节点中的 2 个。
我们修复了该错误，CPU 部署修复程序后 RAM 使用率立即恢复到正常水平。
自从我们将 cassandra 集群从版本 2.0.17 升级到 2.1.15 后，我们遇到了 3 节点集群中的 2 个节点的问题。
他们一直比另一个 cpu 使用更多。更仔细的调查似乎表明它取决于 GC - 当我使用 jstat -gc 跟踪所有 3 个 cassandra 进程时，我可以看到节点 1 和 3 的 GC 频率比节点 2 高得多。
这也从 cassandra 日志中显示出来，除此之外，GC 似乎还很慢：
INFO [Service Thread] 2017-07-31 16:17:35,655 GCInspector.java:258 - ParNew GC in 210ms. CMS Old Gen: 562659176 -> 612323584; Par Eden Space: 411959296 -> 0; Par Survivor Space: 49544256 -> 51445760
INFO [Service Thread] 2017-07-31 16:17:41,694 GCInspector.java:258 - ParNew GC in 525ms. CMS Old Gen: 612323584 -> 764506632; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:17:48,702 GCInspector.java:258 - ParNew GC in 334ms. CMS Old Gen: 823507232 -> 907859304; Par Eden Space: 411959296 -> 0; Par Survivor Space: 39578752 -> 51445760
INFO [Service Thread] 2017-07-31 16:17:58,667 GCInspector.java:258 - ParNew GC in 369ms. CMS Old Gen: 907859304 -> 1006118696; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:18:08,766 GCInspector.java:258 - ParNew GC in 456ms. CMS Old Gen: 1006118696 -> 1123833216; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:18:16,979 GCInspector.java:258 - ParNew GC in 540ms. CMS Old Gen: 1123833216 -> 1286209400; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:18:22,833 GCInspector.java:258 - ParNew GC in 386ms. CMS Old Gen: 1286209400 -> 1395049184; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:18:41,111 GCInspector.java:258 - ParNew GC in 201ms. CMS Old Gen: 801910056 -> 895733880; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:18:43,134 GCInspector.java:258 - ParNew GC in 221ms. CMS Old Gen: 895733880 -> 975905560; Par Eden Space: 411624624 -> 0;
INFO [Service Thread] 2017-07-31 16:19:22,733 GCInspector.java:258 - ParNew GC in 214ms. CMS Old Gen: 1030387520 -> 1079340184; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:19:31,430 GCInspector.java:258 - ParNew GC in 266ms. CMS Old Gen: 1079340184 -> 1166678176; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:19:35,061 GCInspector.java:258 - ParNew GC in 606ms. CMS Old Gen: 1166678176 -> 1353067264; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:19:37,808 GCInspector.java:258 - ConcurrentMarkSweep GC in 2249ms. CMS Old Gen: 1353067264 -> 477397536; Par Eden Space: 411936152 -> 0; Par Survivor Space: 51445760 -> 0
INFO [Service Thread] 2017-07-31 16:19:48,769 GCInspector.java:258 - ParNew GC in 362ms. CMS Old Gen: 695828520 -> 793426632; Par Eden Space: 411959296 -> 0; Par Survivor Space: 40276928 -> 51445760
INFO [Service Thread] 2017-07-31 16:19:58,710 GCInspector.java:258 - ParNew GC in 376ms. CMS Old Gen: 793426632 -> 899121400; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:20:23,431 GCInspector.java:258 - ParNew GC in 225ms. CMS Old Gen: 1067967744 -> 1139648600; Par Eden Space: 411629080 -> 0; Par Survivor Space: 40055056 -> 51445760
INFO [Service Thread] 2017-07-31 16:20:24,988 GCInspector.java:258 - ParNew GC in 210ms. CMS Old Gen: 1161527408 -> 1226340808; Par Eden Space: 411959296 -> 0;
INFO [Service Thread] 2017-07-31 16:20:27,596 GCInspector.java:258 - ConcurrentMarkSweep GC in 236ms. CMS Old Gen: 1161527408 -> 477824664; Par Eden Space: 325760 -> 56800072;
INFO [Service Thread] 2017-07-31 16:21:24,879 GCInspector.java:258 - ParNew GC in 574ms. CMS Old Gen: 705116088 -> 868474072; Par Eden Space: 411959296 -> 0;
将 max heap 和 new heap 从 1966M 和 491M 分别增加到 2500M 和 1024M 似乎影响不大。值一一调整，中间 nodetool drain 和 cassandra 服务重启。
我也试过减轻这个集群的所有负载，这确实对 cassandra cpu 的使用有影响 - 但节点 1 和 3 继续使用更多 cpu。
更高的 cpu 使用率不是恒定的 - 它在 'normal' 和高之间来回波动，这似乎与 GC 运行相关。
我无法确定可能的原因以及如何进一步调查。非常感谢任何想法。
2.5gb 的堆对于 C* 实例来说小得离谱。不要期望任何低于 8gb 的东西在没有大量 GC 的情况下做很多工作，它根本不是为此设计的。考虑到每 5-10 秒左右的 200-500 毫秒 gc，所有事情都非常好。 见 http://docs.datastax.com/en/landing_page/doc/landing_page/planning/planningHardware.html#planningHardware__memory
For both dedicated hardware and virtual environments, the recommended memory is:
Production 32 GB to 512 GB; the minimum is 8 GB for Cassandra nodes.
Development in non-loading testing environments: no less than 4 GB.
Heap size is usually between ¼ and ½ of system memory.
Cassandra automatically calculates the maximum heap size (MAX_HEAP_SIZE) based on this formula:
max(min(1/2 ram, 1024MB), min(1/4 ram, 8GB)The recommended maximum heap size depends on which GC is used: Older computers Typically 8 GB. CMS for newer computers (8+ cores) with up to 256 GB RAM No more 14 GB.
通常，当您查看您认为是 cassandra 问题的问题时，结果证明这是我们自己的错。我们在一个过程中有一个错误，导致它不断地创建、查询和删除单个特定键的记录。这意味着它正在创建大量的墓碑，并且查询正在命中越来越多的墓碑。复制因子也设置为 2，解释了为什么它只影响 3 个节点中的 2 个。
我们修复了该错误，CPU 部署修复程序后 RAM 使用率立即恢复到正常水平。