cassandra-commits mailing list archives

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

    [ https://issues.apache.org/jira/browse/CASSANDRA-12248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15527741#comment-15527741
] 

Nate McCall commented on CASSANDRA-12248:
-----------------------------------------

Yeah, I missed it. [~dikanggu] Jake is correct. CompactionManager.setConcurrentCompactors
should have the setMaxPoolSize first, followed by core. I've actually done this wrong when
poking these via JMX (slide 75 here: http://www.slideshare.net/zznate/advanced-apache-cassandra-operations-with-jmx).


Good catch, [~tjake]. 

> 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