cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <j...@apache.org>
Subject [jira] [Reopened] (CASSANDRA-12248) Allow tuning compaction thread count at runtime
Date Tue, 27 Sep 2016 12:16:22 GMT

     [ 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)

Mime
View raw message