最近我们插入了数百万条记录并从表中删除了数百万条记录，大小为10 GB的表格被截断。
我们使用SizeTieredCompactionStrategy运行2个节点，当前CPU利用率为100％且待定压缩正在增加，当前待定压缩为293144
任何降低CPU利用率并快速完成压缩的指针。
答案 0 :(得分：6)
降低CPU利用率并快速完成压缩。
这两件事是正交的。您可以加快压缩（通过使用更多资源）或限制压缩的资源，这样您的写入就不会受到影响，但需要更长的时间。
如果你的cassandra集群有一个ingest运行，我会尽量确保它不受你的压缩影响。只要等待的压缩＃随着时间的推移而减少，这只是一个时间问题。
如果您没有进行读写操作（I.E.停机时间或您进行自举），可以让压缩耗尽所有资源并快速完成。
杠杆是：
1）获取/设置压缩吞吐量（nodetool） - 仅启动下一个可用的压缩。这就是压实发生的速度。如果您有可用资源，则默认值为16 mb / s，您可以将其增加到更大的数字。
2）并发压缩器 - 您必须在JMX中设置2个值。您可以使用jmxsh或jconsole等动态执行此操作。这是您一次可以运行的压缩次数（核心数）。
观察nodetool compactionstats或OpsCenter（您还可以绘制待处理的压缩和设置警报）以查找当前压缩的进度或nodetool comactionhistory已完成的压缩。
大小为10 GB的表被截断。
截断是免费的，不需要压缩。