[jira] [Updated] (CASSANDRA-18619) nodetool garbagecollect does not use all available compaction executors

["Stefan Miklosovic (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-18619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Miklosovic updated CASSANDRA-18619:
------------------------------------------
    Summary: nodetool garbagecollect does not use all available compaction executors  (was: nodetool compaction does not use all available compaction executors)

> nodetool garbagecollect does not use all available compaction executors
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-18619
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-18619
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Stefan Miklosovic
>            Priority: Normal
>
> Lets have a node with 8 cores and lets do "nodetool setconcurrentcompactors 4"
> When I am doing "nodetool garbagecollect", there is a possibility to specify number of "jobs" via -j flag. If I set it to "2", max two threads will be compacting, if I set it to 6, it will be in practice capped to 4 as that is my "concurrentcompactors" setting.
> So far good.
> However, when I set jobs to 4 and I execute garbagecollecting on two tables, tb1 and tb2 like this:
> {code}
> nodetool garbagecollect -j 4 -- keyspace1 tb1 tb2
> {code}
> What it does is that it will start to gc first table, 4 tables at max AND THEN it will start to gc the second table.
> In other words, if tb1 has 10 tables to gc and I have 4 jobs at max, it will gc them, but if one looks into compactionstats, she sees that as gc-ing progresses, there might be e.g. just 2 tables left to gc so in theory there is a slot for two additional sstables to gc-ed as well but this will not happen. It will wait until the first table is gc-ed and then it will start to gc the second one with 4 threds.
> This might be improved so as soon as there is a free job thread  to gc, next sstable would be scheduled to be gc-ed even it is from a different cql table.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org