我们在4个数据中心拥有30多个节点的cassandra群集（3.11.2）。其中一个中心由azure中的8个节点组成，这些节点运行在标准ds12 v2（4cpu，28gb）节点上，带有500gb高级ssd驱动器。都在同一个数据中心（美国中部）。
当节点活动被推到最大值时，我们看到了一个显著的cpu不平衡。我们有一个包含约2亿条记录的键空间，并且我们正在运行一个进程来检查和刷新另一个数据流中的记录（如果需要）。
现在的情况是，我们有4个节点运行在70-90%的cpu上，而其他4个节点的cpu为15-25%。cpu的度量是在节点本身中进行的，因为azure自己的度量被破坏了，永远不能代表实际发生的事情。
深入研究一对节点（一个低cpu，一个高cpu），两者的区别是iowait%。键空间中的数据是平衡的（在合理范围内-它们在记录计数和大小上都在另一个的5%以内）。看起来读取次数是平衡的，甚至cassandra报告的读取延迟也是相似的。
当我对节点进行iostat比较时，高cpu节点报告的rkb/s数要高得多（50%到100%）。。。这可能导致iowait%时间的差异。
这些节点的配置都是100%相同的，运行的所有东西（操作系统、库、所有东西）的版本都是相同的。我不明白为什么有些节点决定执行比其他节点更多的磁盘读取，从而导致整个集群的速度减慢。
有人对我在哪里能找到不同有什么建议吗？
唯一的一点是一个模式，是较慢的节点是4个节点，这4个节点是后来在我们的扩展中添加的。我们从4个节点开始了一段时间，当我们需要空间时又增加了4个节点。添加节点所需的所有适当修复和其他任务都已完成—磁盘上数据文件的记录和物理大小相等的事实应证明这一点。
当我们关闭刷新过程时，所有节点的cpu都稳定在5%或更少。没有压实或任何其他维护发生，这将表明一些不同的东西。
plz帮助…：）