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

Reply via email to