cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-12300) Disallow unset memtable_cleanup_threshold when flush writers is set
Date Wed, 27 Jul 2016 00:06:20 GMT

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

Ariel Weisberg commented on CASSANDRA-12300:
--------------------------------------------

I agree that advice is awful and needs to DIAF due to what changing flush writers does to
MCT. I think think setting MCT based on flush writers makes sense though and I would even
say that it seems like MCT should not be an option at all since it the correct value can be
derived from knowing the total memory available for memtables and the # of flush writer

I'm not sure your formula makes sense since # of tables shouldn't impact flush throughput.
Necessary flush throughput is a function of # of megabytes/second you need to flush which
is a function of ingest speed. Ingest performance to a point should be the same whether you
have on table or a heaping handful. I don't think # of cores even really enters into it since
more flush threads than you need necessarily implies flushing tables sooner than you otherwise
could if you waited and let them grow a bit bigger.

Maybe practical experience is different. I never benchmark writing to multiple tables so I
am going off of my own theory here.

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

Mime
View raw message