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

T Jake Luciani reopened CASSANDRA-12248:
----------------------------------------

I'm pretty sure there is a bug in here (though I haven't tested it to prove).  
The max threads can never be > than the core threads so the order you set these 
depends on the current value.  So if you are lowering the number of threads you 
need to lower the core threads first followed by the max.  If you are 
increasing the threads you need to first set the max then the core...

> Allow tuning compaction thread count at runtime
> -----------------------------------------------
>
>                 Key: CASSANDRA-12248
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12248
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Tom van der Woerdt
>            Assignee: Dikang Gu
>            Priority: Minor
>             Fix For: 3.10
>
>
> While bootstrapping new nodes it can take a significant amount of time to 
> catch up on compaction or 2i builds. In these cases it would be convenient to 
> have a nodetool command that allows changing the number of concurrent 
> compaction jobs to the amount of cores on the machine.
> Alternatively, an even better variant of this would be to have a setting 
> "bootstrap_max_concurrent_compactors" which overrides the normal setting 
> during bootstrap only. Saves me from having to write a script that does it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to