azure中的cassandra cpu不平衡

djmepvbi  于 2021-06-14  发布在  Cassandra
关注(0)|答案(1)|浏览(512)

我们在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帮助…:)

6ioyuze2

6ioyuze21#

我们对此的最终解决方案——只解决不平衡的问题,就是清理、全面修复和压缩。在这一点上,节点的使用相对平等。我们怀疑扩展集群(添加节点)可能会导致旧节点上的数据元素未根据常规压缩事件压缩。
我们仍在努力解决负荷问题;但现在至少所有的节点都感觉到了同样的cpu问题。

相关问题