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