我有 3 节点集群。 3 个节点中有 2 个显示 100% 的 CPU 使用率。
似乎我们在更改一致性级别后没有调用repair 和cleanup（或者我们调用它太晚了或者它没有完成）
现在我们有 10 万个以上的压缩任务待处理。他们吃掉 100% 的 CPU。
我试过了
nodetool stop -- COMPACTION
nodetool stop -- INDEX_BUILD
nodetool stop -- VALIDATION
nodetool stop -- CLEANUP
nodetool stop -- SCRUB
没有变化。也没有错误。
我收到的唯一消息是
No files to compact for user defined compaction
什么问题？我怎样才能取消正在进行的工作？
【问题讨论】：
调用nodetool stop COMPACTION 将停止当前的压缩。如果您不希望它开始新的压缩，请使用nodetool disableautocompaction。然后可以通过nodetool compactionstats进行验证
我确信这不是你的问题。如果有 100k 的待定压缩，您将拥有太多的 sstable。你的节点无可救药地落后了。任何读取都会导致大量负载。此外，除非你有一个巨大的堆，否则仅仅试图从它们中读取可能会导致你在堆空间和 GC 问题上运行不足。 GC 可能是您的高负载的原因，如果您检查您的 CPU 时间，如果它花费在 IO 上，它可能来自读取或流式传输，如果它在 sys/usr 中，它可能是 GC。如果是 GC 问题，您可以进行堆转储并检查以验证占用所有空间的内容。
如果您的节点落后 100k，您的节点可能永远无法自行恢复。您最好的选择可能是以下之一：
nodetool disablebinary/disablethrift/disablegossip 将其从集群中删除，然后使用nodetool compact 强制压缩所有sstables。根据版本和压缩策略，它可能无法正常工作，但您可以使用 jmx 在本地将该节点的压缩策略更改为 STCS 以使其工作。如果这不能在提示的切换窗口中完成，那么尝试再次使您的集群保持一致是不值得的。此外，这仅在从集群中删除节点时负载下降时才有效。【讨论】：