我们在4个数据中心中拥有30多个节点的Cassandra集群（3.11.2）。其中一个中心由Azure中的8个节点组成，它们在具有500GB高级SSD驱动器的Standard DS12 v2（4cpu，28gb）节点上运行。全部位于同一数据中心（美国中部）。
当节点活动达到最大时，我们看到节点活动中的CPU严重失衡。我们有一个大约有2亿条记录的键空间，并且正在运行一个过程，以在必要时从另一个数据流中检查和刷新记录。
正在发生的事情是，我们有4个节点以70-90％的CPU运行，而其他4个节点的运行率为15-25％。CPU的测量是在节点本身中完成的，因为Azure自己的指标已被破坏永远不会代表实际发生的事情。
挖掘到一对节点（一个低CPU和一个高CPU）的区别是两个节点的iowait％。键空间中的数据是平衡的（出于一定原因-它们的记录数和大小都在另一个值的5％之内）。看起来读取次数是均衡的，甚至Cassandra报告的读取延迟也是如此。
当我对节点进行iostat比较时，高CPU节点报告的rKB / s值更高（提高了50％至100％）...这很可能导致iowait％时间上的差异。
这些节点100％配置为相同，并且运行所有可以想到的相同版本（操作系统，库，所有内容）。我无法弄清楚为什么有些节点决定执行更多的磁盘读取操作，而其他节点却导致整个群集速度变慢。
有人对我在哪里可以找到差异有任何建议吗？
唯一的一种模式是，速度较慢的节点是在扩展中稍后添加的4个节点。我们从4个节点开始了一段时间，然后在需要空间时又增加了4个。添加节点所需的所有适当的维修和其他任务均已完成-磁盘上数据文件的记录和物理大小相等的事实应证明这一点。
当我们关闭刷新过程时，所有节点的全部CPU稳定下来甚至达到5％或更少。没有进行压缩或进行任何其他维护工作，这表明有所不同。
plz帮助...：）
答案 0 :(得分：0)
为此，我们最终的解决方案-仅解决不平衡的问题是清理，全面修复和紧凑化。在那一点上，节点被相对平等地使用。我们怀疑扩展群集（添加节点）可能会使旧节点上的数据元素因常规压缩事件而未被压缩。
我们仍在努力解决负载问题；但是现在至少所有节点都感到CPU紧缩。