Cassandra 2.1集群显示始终如一的高CPU使用率和缓慢的响应

Question

5月3日我们部署了。我们的3节点cassandra集群变得极其缓慢，许多Web请求都超时。通过EOD 5月3日，我们向我们的集群启动了另一台m1.large机器，解决了超时问题。话虽这么说，集群仍然非常缓慢; 5月4日，我们推出了5个i3.xLarge节点。这大大有助于我们的应用程序响应时间，5月5日我们从群集中删除了旧的m1.large框。截至5月5日的EOD，一切都快速响应。今天早上，应用程序再次开始计时。

我们注意到一些奇怪的CPU利用率行为 - 无论负载如何，CPU使用率在100％和200％之间波动（它们是四个核心机器）。我们有非常轻的周末，绝对没有负载和相对较重的星期一负载，但我们看到CPU使用率绝对没有变化。

正如您在下面的2周图表中所看到的，我们的数据库CPU使用率曾被绑定到应用程序使用情况。您可以看到第3个中的大峰值，第4个新机器的引入，以及从6日开始的稳定的高CPU使用率。

我们花了很多时间来确定CPU使用的原因，并且能够识别（并随后排除）三个主要原因：

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

我们排除了所有这三件事。

1. 我们的服务器拥有0.0％的khugepaged CPU使用率。
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线程的状态显示绝大多数都在使用以下堆栈跟踪进行WAITING：

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线程，偶尔会有一两个处于挂起状态。没有被阻止，所有时间被阻止或被丢弃。

以下是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添加到问题中吗？

Answer 2

问题实际上是我们的API。它有GC问题导致大量的db读/写线程被冻结。