Cassandra 集群中的突然负载峰值

Question

最近我们的 Cassandra 集群开始出现问题。也许有人对如何解决这个问题有想法。我们在 40 个节点的集群上运行 Cassandra 3.11.7。我们使用复制因子 = 3 并在一致性级别 QUORUM 上读/写。

最近，单个节点经历了 CPU 负载的突然峰值，然后持续了一段时间。在此期间，我们可以观察到大量丢弃和排队的 MUTATION。如果我们在有问题的节点上重新启动 Cassandra，那么一两个其他节点就会开始遇到同样的问题。我们检查了日志文件和访问模式，但尚未找到原因。

此类行为的最常见原因可能是什么？我们应该在哪里仔细观察？有没有人有过类似的经历？

Answer 1

如果我们在有问题的节点上重新启动 Cassandra，那么一两个其他节点就会开始遇到同样的问题。

首先，当单个节点出现问题时，重新启动它通常没有任何效果。如果有的话，您将清除 JVM 堆...在启动时将很快重新填充。说真的，不要指望重启节点来修复任何问题。

有没有人有过类似的经历？

是的，好几次。对于与 Cassandra 无关的事情：

• 您在云环境中吗？运行iostat 并查找iowait 和steal 的高百分比。有时共享资源不能很好地与其他人一起使用。如果您没有 iostat，请获取 (yum install -y sysstat)。
• 检查所有用户的 cron。我们曾经遇到过将文件完整性检查器作为基础映像的一部分进行安装的问题，而它正是您所说的。

这种行为最常见的原因是什么？我们应该在哪里仔细观察？

对于 Cassandra 相关问题，我看到了一些可能性：

• 维修。检查节点是否正在运行修复。您可以使用 nodetool compactionstats 查看 Merkle Tree 计算，使用 nodetool netstats 修复流。
• 压实。检查nodetool compactionstats。如果是这样，您可以尝试降低压缩吞吐量，以免影响正常操作。
• 垃圾收集。检查gc.log.* 文件。如果是 GC，通常可以通过阅读和调整 GC 设置来修复它。如果您的团队中没有任何人是 JVM GC 专家，我建议使用 G1GC，因为它可以消除很多猜测。

请注意，我上面提到的所有内容都永远可以通过重新启动来修复。事实上，它很可能会从上次中断的地方重新开始。