cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Stump (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8150) Simplify and enlarge new heap calculation
Date Thu, 20 Nov 2014 22:40:34 GMT

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

Matt Stump commented on CASSANDRA-8150:
---------------------------------------

I don't disagree with your experience but I do disagree with the description of what is happening.
 With the GC frequency that I described above the memtable will be moved to tenured space
after about 60-80 seconds. All of the individual requests will create ephemeral objects which
would be ideally handled by ParNew. 

Where we went wrong was growing the heap but not also increasing MaxTenuringThreshold. By
default we set MaxTenuringThreshold to 1 which means promote everything that survives 2 GCs
to tenured, which coupled with a small heap for the workload results in a very high promotion
rate which is why we see the delays. The key is to always increase MaxTenuringThreshold and
young gen more or less proportionally.  From the perspective of GC and the creation rate for
ephemeral objects reads and writes are more or less identical. One could possibly even make
the case that writes are even better suited for the settings I've outlined above because writes
should put less presure on eden due to the simpler request path. In my opinion, and I hope
to have data to back this up soon, is that write heavy vs read heavy GC tuning I think is
mostly a red herring. 

> Simplify and enlarge new heap calculation
> -----------------------------------------
>
>                 Key: CASSANDRA-8150
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8150
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Config
>            Reporter: Matt Stump
>            Assignee: Brandon Williams
>
> It's been found that the old twitter recommendations of 100m per core up to 800m is harmful
and should no longer be used.
> Instead the formula used should be 1/3 or 1/4 max heap with a max of 2G. 1/3 or 1/4 is
debatable and I'm open to suggestions. If I were to hazard a guess 1/3 is probably better
for releases greater than 2.1.



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

Mime
View raw message