Question

由于我们已将cassandra集群从2.0.17升级到2.1.15，因此我们遇到了来自3节点集群的2个节点的问题。

他们一直在使用比另一个更多的cpu。更严格的调查似乎表明它已经归结为GC - 当我使用jstat -gc跟踪所有3个cassandra进程时，我可以看到节点1和3比节点2更频繁地使用GC。

这也显示了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;

将最大堆和新堆从1966M和491M分别增加到2500M和1024M似乎没什么影响。值逐一调整，nodetool drain和cassandra服务重新启动。

我还尝试从该群集中获取所有负载，这对cassandra cpu的使用有影响 - 但是节点1和3继续使用相当多的cpu。

较高的CPU使用率不是恒定的 - 它在“正常”和“正常”之间来回传递。和高，这似乎与GC运行相关。

我无法确定原因可能是什么以及如何进一步调查此问题。非常感谢任何想法。

Answer 1

对于C *实例，2.5gb堆非常小。不要期望任何低于8gb的东西在没有大型GC的情况下做很多工作，它根本就不是为此而设计的。考虑到每5-10秒左右200-500ms gc的所有事情都非常好。见http://docs.datastax.com/en/landing_page/doc/landing_page/planning/planningHardware.html#planningHardware__memory

对于专用硬件和虚拟环境，建议的内存为：

生产32 GB至512 GB; Cassandra节点的最小值为8 GB。

在非加载测试环境中开发：不低于4 GB。

堆大小通常介于系统内存的¼和½之间。

Cassandra根据以下公式自动计算最大堆大小（MAX_HEAP_SIZE）：max(min(1/2 ram, 1024MB), min(1/4 ram, 8GB)

建议的最大堆大小取决于使用的GC：   较旧的计算机通常为8 GB。   CMS用于较新的计算机（8个核心），最高256 GB RAM不超过14 GB。

Answer 2

通常当你看到一个你认为是cassandra问题的问题时，结果证明这是我们自己的错。我们在进程中遇到了一个错误，导致它不断创建，查询和删除单个特定键的记录。这意味着它正在创建大量的墓碑，并且查询正在越来越多的墓碑。复制因子也设置为2，解释了为什么它只影响了3个节点中的2个。

我们已经修复了错误，并且在部署修复程序后，CPU和RAM使用率立即恢复到正常水平。

Cassandra在特定节点上有很多GC

2 个答案: