Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 26 Jul 2016 23:33:20 +0000 (UTC)
From: "Brandon Williams (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12992637.1469551441000.140652.1469576000593@Atlassian.JIRA>
In-Reply-To: <JIRA.12992637.1469551441000@Atlassian.JIRA>
References: <JIRA.12992637.1469551441000@Atlassian.JIRA> <JIRA.12992637.1469551441142@arcas>
Subject: [jira] [Commented] (CASSANDRA-12300) Disallow unset
 memtable_cleanup_threshold when flush writers is set
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 26 Jul 2016 23:33:22 -0000


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

Brandon Williams commented on CASSANDRA-12300:
----------------------------------------------

I think part of it is our somewhat bad advice:

{noformat}
# If your data directories are backed by SSD, you should increase this
# to the number of cores.
#memtable_flush_writers: 8
{noformat}

Oh, I have SSD, I'll set this to the number of cores.  In reality, I think what you want to set this to is min(active_tables+fudge, num_cores).  Instead when you do just blindly set this to the number of cores, you can get a huge divisor for mct if unset, and create a bunch of very small sstables (I've seen as bad as a handful or two of kilobytes.)

> Disallow unset memtable_cleanup_threshold when flush writers is set
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-12300
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12300
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Brandon Williams
>
> Many times I see flush writers set, and mct unset, leading to a very small mct, which causes unneeded frequent flushing, and then of course compaction.  I also think the default is a bit conservative, typically ending up at 0.11, where I'd say the majority of use cases only have one or two hot tables and are much better served at 0.7 or 0.8.


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