卡桑德拉2.1集群显示持续的高CPU占用率和响应速度很慢

在我们部署了5月3日。我们的3节点cassandra集群变得非常缓慢，许多web请求都超时了。 EOD 5月3日，我们推出了另一台m1.large机器来解决超时问题。话虽如此，该集群仍然非常缓慢; 5月4日我们推出了5个i3.xLarge节点。这对我们的应用程序响应时间有相当大的帮助，5月5日我们从集群中删除了旧的m1.large。截至5月5日为止，所有事情都很快速且响应迅速。今天早上，应用程序再次开始超时。卡桑德拉2.1集群显示持续的高CPU占用率和响应速度很慢

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

正如你可以在下面2周图看，我们的数据库CPU使用率一度被绑定到应用程序的使用。您可以看到第3台的大幅增长，第4台新机的推出，以及从6日开始的稳定的高CPU使用率。

我们已经花了很多时间试图找出CPU使用率是一个好的量，并能识别（和随后排除）主要有三个原因：

High khugepaged CPU usage.
调整不当的垃圾收集
调整不准确

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

我们的服务器有0.0％的khugepaged CPU使用率。
我们的GC通量约为96％。我们还调整了堆和新的堆大小以及切换到G1 GC。我们的日志曾经显示与长时间的GC暂停相关的警告，但不再执行。此外，GC线程仅占用少量的CPU使用量。
nodetool compactionstats返回0，尚未完成的任务。我们已经切换到LeveledCompactionStrategy并将GC_GRACE_SECONDS设置为1天。我们的日志曾经显示与大量墓碑相关的警告，但不再提供。 nodetool compactionhistory显示每小时约一次压实，并且根据它们发生的日志非常快（< 1秒）。

看来卡桑德拉的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一工作者线程的状态表明，绝大多数都是与以下堆栈跟踪等待：

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

有谁有关于为什么这可能发生的任何想法？我们可以研究哪些潜在的事物？

来源

2017-05-08 cscan

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

来源

2017-05-11 23:10:02 cscan

它可以与高数量的墓碑或高数量的扫描单读sstables的 - 即，由于高量产生恒定高CPU负载和较慢的响应的读取它需要为每一个请求做。

这些症状可以显示，例如，使用STCS持续和频繁地更新（更新行，而不是添加新数据）数据。

您可以添加主表的nodetool tablestats/cfstats的问题？

来源

2017-05-09 10:20:39 nevsv

我已经更新了问题，包括'nodetool cfstats'和'nodetool netstats'。它看起来像'nodetool tablestats'与卡桑德拉3.沿第一个版本，我们也切换到LeveledCompactionStrategy正是由于这个原因。 – cscan

去LCS应该是一个不错的选择。如果数据更新频繁，请考虑将gc_grace设置为较低的值。关于cfststs - 表边存储看起来有问题，每个切片读取大量的逻辑单元。 – nevsv

卡桑德拉2.1集群显示持续的高CPU占用率和响应速度很慢

回答

相关问题