取消Cassandra中正在进行的压缩作业

我有3个节点集群。 3个节点中的2个显示100％的CPU使用率。取消Cassandra中正在进行的压缩作业

看来我们没有不叫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

请告诉我问题？我怎样才能打好工作？

来源

2017-07-31 Jigar Shah

调用nodetool stop COMPACTION将停止当前的压缩。如果你不想让它开始新的压缩使用nodetool disableautocompaction。然后可以验证nodetool compactionstats

但我确定这不是你的问题。有了100k的待定压缩，你将会有太多的sstables。你的节点无可救药地落后了。任何读取都会导致巨大的负载。另外，除非你有一个巨大的堆，否则只是试图读取它们可能会导致你在堆空间和GC问题上运行得很慢。如果你检查你的CPU时间，如果它在IO中可能来自读取或流式传输，如果它在sys/usr中它可能是GC，那么GC可能是你高负载的原因。如果它出现GC问题，您可以采取堆转储并检查以确定哪些空间需要占用。

节点后面100k可能永远不会自行恢复。你最好的选择可能是：

Replace它甚至有它自己取代。
从群集中删除它nodetool disablebinary/disablethrift/disablegossip然后使用nodetool compact强制压缩所有sstable。根据版本和压缩策略，它可能不起作用，但您可以使用jmx将本地节点的压缩策略仅更改为STCS，以使其工作。如果不能在暗示的切换窗口中完成，则不值得再次尝试使群集保持一致的麻烦。此外，只有当从群集中删除节点时负载下降时才会起作用。
安装程序监视和警报，从不让它远远落后。目标子100正在等待压缩。

来源

2017-07-31 15:08:26

问题是，它甚至没有停止当前挂起/正在运行的任务。（它会停止等待吗？） –

挂起是估计需要多少任务才能进入“正确”状态。取消进行中的任务不会改变这一点。 nodetool停止将取消当前运行（当它可以），并且disableautocompaction将阻止它自动启动下一个。但是，再一次，压缩不是问题，问题是你远远落后。 –

取消Cassandra中正在进行的压缩作业

回答

相关问题