Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 11 Feb 2015 17:07:13 +0000 (UTC)
From: "Yuki Morishita (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12774255.1423672370000.15329.1423674433574@Atlassian.JIRA>
In-Reply-To: <JIRA.12774255.1423672370000@Atlassian.JIRA>
References: <JIRA.12774255.1423672370000@Atlassian.JIRA>
 <JIRA.12774255.1423672370268@arcas>
Subject: [jira] [Commented] (CASSANDRA-8787) Decrease Default
 concurrent_compactors from number of CPU
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Yuki Morishita commented on CASSANDRA-8787:
-------------------------------------------

For 2.1+, it is capped by the number of data directories (CASSANDRA-7139).

> Decrease Default concurrent_compactors from number of CPU
> ---------------------------------------------------------
>
>                 Key: CASSANDRA-8787
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8787
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sebastian Estevez
>            Priority: Minor
>             Fix For: 3.0
>
>
> Currently we default concurrent_compactors to the number of avaliable CPUs which means compactions can theoretically take over all threads and prevent reads and writes from happening.
> I'm currently seeing an extreme case of this that is caused by [6405|https://issues.apache.org/jira/browse/CASSANDRA-6405]. But, in general, this is a bad default. We should probably default concurrent_compactors to num_cpu to cores/2 or even cores/4.


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