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

Question

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

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

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

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

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

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

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

我唯一的观察结果可能是导致此问题的原因是有一个名为cassandra-topology.properties的文件，如果使用 GossipingPropertyFileSnitch，则专门告知将其删除

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

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

Answer 1

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

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

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

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

一些尝试：

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