取消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中正在進行的壓縮作業

回答

相關問題