linux - 某些 Cassandra 节点上的高 CPU 使用率和流量

Question

如标题所述，我们的 Cassandra 集群存在问题。使用NetworkTopologyStrategy有9 个节点，复制因子为 3。都在同一个 DC 和机架中。Cassandra 版本是3.11.4（计划在 3.11.10 上移动）。实例有4 个 CPU和32 GB RAM。（计划在 8 个 CPU 上移动）

每当我们尝试在我们的集群上运行修复（在我们的一个节点上使用 Cassandra Reaper）时，我们都会在过程中的某个地方丢失一个节点。我们迅速停止修复，重启节点上的 Cassandra 服务，等待它加入环。因此，这些天我们永远无法进行维修。

我观察了这个问题并意识到这个问题是由我们的一些节点（正好是 3 个）上的高 CPU 使用率引起的。您可能会在下面看到 1 周的间隔图。起伏是由应用程序的使用引起的。在早上，它非常低。

我比较了每个节点上正在运行的进程，在高 CPU 节点上没有什么额外的。我比较了配置。它们是相同的。找不到任何区别。

我还意识到这些节点是占用大部分流量的节点。请参阅下面的 1 周间隔图。发送和接收字节。

我做了一些研究。我找到了这个线程，最后建议dynamic_snitch: false在 Cassandra 配置中进行设置。我查看了我们的告密策略，即GossipingPropertyFileSnitch。在实践中，这种策略应该可以正常工作，但我想它不会。

告密者的工作是提供有关您的网络拓扑的信息，以便 Cassandra 可以有效地路由请求。

我唯一可能导致此问题的观察结果是有一个名为cassandra-topology.properties的文件，如果使用 GossipingPropertyFileSnitch ，该文件被明确告知要删除

本地节点的机架和数据中心在 cassandra-rackdc.properties 中定义，并通过 gossip 传播到其他节点。如果 cassandra-topology.properties 存在，则将其用作后备，允许从 PropertyFileSnitch 迁移。

我没有删除此文件，因为我找不到任何确凿证据证明这是导致问题的原因。如果您对此有任何了解或看到我的问题的任何其他原因，我将感谢您的帮助。

标签： linuxcassandracassandra-3.0

Answer 1

这两句话告诉我一些关于集群的重要信息：

我们的一些节点（正好是 3 个）上的 CPU 使用率很高。

我还意识到这些节点是占用大部分流量的节点。

显而易见的一点是，您的复制因子 (RF) 是 3（最常见）。不那么明显的是，您的数据模型很可能以日期或其他一些自然键为键，这会导致相同的（3 个？）节点长时间为所有流量提供服务。在这些高流量期间进行维修可能会导致问题。

一些事情要尝试：

• 查看数据模型，看看是否有更好的方法来划分数据以在集群的其余部分分配流量。这通常通过称为“bucketing”的建模技术完成（添加另一个组件......通常基于时间......到分区键）。
• 分区大吗？（检查nodetool tablehistograms）和“大”，比如> 10MB？也可能是大分区导致修复操作失败。如果是这样，希望降低资源消耗（如下）会有所帮助。
• 您的集群是否支持高写入吞吐量？如果是这样，它也可能正在处理压缩 ( nodetool compactionstats)。您可以尝试降低压缩吞吐量 ( nodetool setcompactionthroughput) 以释放一些资源。修复操作也可以调用压缩。
• 同样，您也可以nodetool setstreamthroughput在修复期间降低流式传输吞吐量 ( )。修复流数据需要更长的时间，但如果这真的是节点翻倒的原因，那么它可能是必要的。
• 如果您还没有，请设置另一个实例并使用Cassandra Reaper进行维修。它比从 cron 触发要好得多。另外，UI 允许在这里可能需要一些微调的配置。它还可以让您暂停和恢复维修，从中断的地方继续维修。