Question

我们当前正在加载数据的cassandra 2.0.17集群，突然之间集群似乎遇到了跟上压缩任务的问题。这似乎与每个节点一个接一个地脱机以进行固件更新的时间相冲突。

想知道如何挖掘RC，提示赞赏！

还想知道如何确保在分配文件系统之间更好地平衡磁盘[-io]之间的使用。

在压缩过程中，似乎有些CF会创建如下的大型临时文件：

-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 FS有效还是可以更好地传播到更小的文件上，从而加快压缩速度？

EG。可以看到过去7天内一个节点FS使用情况的样本here显示FS blob-3的使用率大幅增加主要是由于上述大型临时文件。这只是因为压缩时间太长了吗？

TIA

Answer 1

看起来你可能正处于紧凑的死亡螺旋式反击中 - ＆gt;更多i / o + CPU读取 - ＆gt;在压缩方面进一步落后。使节点脱机（这意味着他们提供更高的写入级别以便在联机时赶上）可能会引发螺旋式上升。

可以预期你有大量的临时文件，因为压缩的一个方法就是采用多个较小的文件并将它们组合成一个较大的文件。

这可能是一个困难的情况，因为向群集添加节点可能会增加群集加入时的总体负载。有时适用于我们的一种方法是使节点脱机（使用nodetool disablegossip disablethrift和disablebinary）以允许它们在不提供读写操作的情况下赶上压缩。

就根本原因而言，鉴于您的数据量迅速增加且磁盘节点比率非常高（每个节点接近10TB？），我一直在寻找i / o瓶颈 - 增加CPU iowait是一个很好的指示。 / p>

干杯本

如何调查RC在未决合同中的突然增加

1 个答案: