Stefan Miklosovic created CASSANDRA-18619:
---------------------------------------------
Summary: nodetool compaction 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
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: [email protected]
For additional commands, e-mail: [email protected]
