如何调查RC中待定压实的突然增加

Question

有一个cassandra 2.0.17集群，我们目前正在加载数据，突然之间，集群似乎在紧凑任务上遇到了问题。这似乎与每个节点逐个短暂离线以进行固件更新的时间相冲突。

查看我们的OpsCenter Dashboard

想知道如何挖掘一个RC，非常感谢提示！

我还想知道如何在分配的文件系统之间更好地平衡disk-io的使用。

在压缩过程中，一些CFs似乎会创建像这样的大型临时文件：

-rw-r--r--. 1 cass cassandra     43726347 May  5 14:17 KeyspaceBlobStore-CF_Message_1-tmp-jb-22142-CompressionInfo.db
-rw-r--r--. 1 cass cassandra 340293724737 May  5 14:17 KeyspaceBlobStore-CF_Message_1-tmp-jb-22142-Data.db
-rw-r--r--. 1 cass cassandra    266403840 May  5 14:17 KeyspaceBlobStore-CF_Message_1-tmp-jb-22142-Index.db

这在xfs上是否有效，或者是否可以更好地传播到更小的文件上，从而加快压缩速度？

例如：可以看到一个节点的示例文件系统在过去7天的使用情况，here显示文件系统blob-3的使用率大大增加，这主要是由于上面的大临时文件。这只是因为压缩时间太长了吗？

提亚

Answer 1

看起来你可能在紧凑的死亡螺旋中落后于压缩，->更多的i/o + CPU on read，->在压缩上变得更落后。使节点离线(这将意味着它们提供更高的写入级别以在联机时赶上)可能会触发螺旋。

可以预期的是，您会有较大的临时文件，因为压缩所做的其中一件事就是获取多个较小的文件，然后将它们组合成一个较大的文件。

这可能是一种很难摆脱的情况，因为向集群添加节点可能会在它们加入时增加集群上的总体负载。一种有时对我们有效的方法是让节点离线(使用nodetool、disablegossip、disablethrift和disablebinary)，以允许它们在不提供读写服务的情况下赶上压缩。

就根本原因而言，考虑到您快速增长的数据量和非常高的磁盘与节点比率(每个节点接近10TB？)，我会寻找i/o瓶颈- CPU的不断增加是一个很好的迹象。

干杯本