Using nodetool stop -id COMPACTION_UUID(reported in compactionstats), also you could figure it out with nodetool help stop
Sent using https://www.zoho.com/mail/ ---- On Mon, 05 Sep 2022 10:18:52 +0430 Gil Ganz <gilg...@gmail.com> wrote --- onmstester - How can you stop a specific compaction task? stop command stops all compactions of a given type (would be nice to be able to stop specific one). Jim - in my case the solution was actually to limit concurrent compactors, not increase it. Too many tasks caused the server to slow down and not be able to keep up. On Fri, Sep 2, 2022 at 4:55 PM Jim Shaw <mailto:jxys...@gmail.com> wrote: if capacity allowed, increase compaction_throughput_mb_per_sec as 1st tuning, and if still behind, increase concurrent_compactors as 2nd tuning. Regards, Jim On Fri, Sep 2, 2022 at 3:05 AM onmstester onmstester via user <mailto:user@cassandra.apache.org> wrote: Another thing that comes to my mind: increase minimum sstable count to compact from 4 to 32 for the big table that won't be read that much, although you should watch out for too many sstables count. Sent using https://www.zoho.com/mail/ ---- On Fri, 02 Sep 2022 11:29:59 +0430 onmstester onmstester via user <mailto:user@cassandra.apache.org> wrote --- I was there too! and found nothing to work around it except stopping big/unnecessary compactions manually (using nodetool stop) whenever they appears by some shell scrips (using crontab) Sent using https://www.zoho.com/mail/ ---- On Fri, 02 Sep 2022 10:59:22 +0430 Gil Ganz <mailto:gilg...@gmail.com> wrote --- HeyWhen deciding which sstables to compact together, how is the priority determined between tasks, and can I do something about it? In some cases (mostly after removing a node), it takes a while for compactions to keep up with the new data the came from removed nodes, and I see it is busy on huge compaction tasks, but in the meantime a lot of small sstables are piling up (new data that is coming from the application, so read performance is not good, new data is scattered in many sstables, and probably combining big sstables won't help reduce fragmentation as much (I think). Another thing that comes to mind, is perhaps I have a table that is very big, but not being read that much, would be nice to have other tables have higher compaction priority (to help in a case like I described above). Version is 4.0.4 Gil
