java - Cassandra 2.1 集群显示出持续较高的 CPU 使用率和缓慢的响应

Question

5 月 3 日，我们部署了。我们的 3 节点 cassandra 集群变得非常慢，许多 Web 请求超时。截至 5 月 3 日 EOD，我们向集群启动了另一台 m1.large 机器，解决了超时问题。话虽如此，集群的速度仍然非常慢； 5 月 4 日，我们启动了五个 i3.xLarge 节点。这极大地缩短了我们的应用程序响应时间，5 月 5 日，我们从集群中删除了旧的 m1.large 盒子。截至 5 月 5 日 EOD，一切都快速且响应迅速。今天早上，应用程序再次开始超时。

我们注意到一些奇怪的 CPU 使用行为 - 无论负载如何，CPU 使用率都会在 100% 和 200% 之间波动(它们是四核机器)。我们的周末非常轻松，完全没有负载，而周一负载相对较高，但我们发现 CPU 使用率完全没有变化。

正如您在下面的 2 周图表中看到的，我们的数据库 CPU 使用率曾经与应用程序使用率绑定(bind)。您可以看到 3 日出现大幅峰值，4 日引入新机器，6 日开始稳定的高 CPU 使用率。

我们花费了大量时间试图找出 CPU 使用率的原因，并能够识别(并随后排除)三个主要原因:

1. High khugepaged CPU usage.
2. 垃圾收集调整不当
3. 压缩调整不当

我们已经排除了所有这三种情况。

1. 我们的服务器的 CPU 使用率是 0.0% khugepaged。
2. 我们的 GC 吞吐量约为 96%。我们还调整了堆和新的堆大小以及切换到 G1 GC。我们的日志曾经显示与长时间 GC 暂停相关的警告，但现在不再显示。此外，GC 线程仅占用少量 CPU 使用率。
3. nodetool compactionstats 返回 0 个待处理任务。我们已切换到 LeveledCompactionStrategy 并将 GC_GRACE_SECONDS 设置为 1 天。我们的日志曾经显示与大量墓碑相关的警告，但现在不再显示。 nodetool Compactionhistory 显示每小时大约一次压缩，并且根据日志，它们发生得非常快(< 1 秒)。

看来 Cassandra 的 SharedPoolWorker 线程的使用率非常高。以下是按线程类型划分的一个节点的 CPU 使用情况(它们看起来都非常相似):

84.6 SharedPoolWorker
22.1 Thrift
13.5 CCompilerThread
11.9 MessagingServiceOutgoing
9.4  MessagingServiceIncoming
3.6  GangworkerParallelGCThreads
1.6  DestroyJavaVM
.3   VMThread
.1   Thread
.1   ScheduledTasks
.1   OptionalTasks
0    ...

检查 SharedPool-Worker 线程的状态表明绝大多数线程处于等待状态，堆栈跟踪如下:

java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    at java.util.concurrent.locks.LockSupport.park(Unknown Source)
    at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:85)
    at java.lang.Thread.run(Unknown Source)

我认为这就是问题所在，但我不确定为什么这可能是因为等待花费的 CPU 时间很少(根据 dstat 始终为 0%)。

现在，有趣的是，在任何给定节点上运行 nodetool tpstats 都会显示少量 ReadStage 线程处于 Activity 状态，偶尔有一两个处于挂起状态。没有被阻止、所有时间被阻止或被丢弃。

这是 nodetool cfstats 的输出这是nodetool netstats:

Mode: NORMAL
Not sending any streams.
Read Repair Statistics:
Attempted: 12229
Mismatch (Blocking): 2
Mismatch (Background): 0
Pool Name                    Active   Pending      Completed   Dropped
Commands                        n/a         0         707576         0
Responses                       n/a         0         859216       n/a

有人知道为什么会发生这种情况吗？我们可以研究任何潜在的事情吗？

Answer 1

这可能与单次读取扫描的大量逻辑删除或大量 sstables 有关 - 由于每个请求需要执行大量读取，因此会造成持续的高 CPU 负载和缓慢的响应。

这些症状可能表明，例如，使用 STCS 来不断且频繁地更新(更新行，而不是添加新行)数据。

您可以将主表的nodetool tablestats/cfstats 添加到问题中吗？