我有3个节点集群。 3个节点中的2个显示100％的CPU使用率。
似乎我们在更改一致性级别后没有调用repair和cleanup（或者我们称之为太晚或者没有完成）
现在我们有100k加上正在进行的压缩任务。他们吃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
什么问题？我怎样才能取消上班？
答案 0 :(得分：2)
调用nodetool stop COMPACTION会停止当前的压缩。如果你不想让它开始新的压缩，请使用nodetool disableautocompaction。然后可以使用nodetool compactionstats
我确信这不是你的问题。有了100k未决的压缩，你将拥有太多的sstables。你的节点落后了。任何读取都会导致大量负载。除非你有一个庞大的堆，只是尝试从它们读取可能会导致你在堆空间和GC问题上运行不足。如果您检查CPU时间，那么GC很可能是您负载过高的原因，如果它在IO中花费了很多时间，那么它可能来自读取或流式传输，如果它在sys / usr中可能是GC。如果它是GC问题，你可以进行堆转储并检查以确认是否占用了所有空间。
在您的节点后面100k可能永远不会自行恢复。你最好的选择可能是：
nodetool disablebinary/disablethrift/disablegossip从群集中删除它，然后使用nodetool compact强制压缩所有sstables。根据版本和压缩策略，它可能不起作用，但您可以使用jmx将本地节点的压缩策略仅更改为STCS以使其工作。如果无法在提示的切换窗口中完成，那么尝试使群集再次保持一致并不值得。此外，只有在从群集中删除节点时负载下降时，此方法才有效。