时间戳

首页 > 解决方案 > Cassandra 集群中的突然负载峰值

cassandra - Cassandra 集群中的突然负载峰值

问题描述

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

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

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

标签： cassandra

解决方案

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

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

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

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

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

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

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

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

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

推荐阅读