[
https://issues.apache.org/jira/browse/CASSANDRA-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14233202#comment-14233202
]
Pierre Laporte commented on CASSANDRA-8150:
-------------------------------------------
[~mstump] By any chance, have you collected Cassandra gc logs against various
scenarios? That would be really valuable to find the right values.
I ran a test of java-driver against a C* instance on GCE n1-standard-1 server
(1 vCPU, 3,75 GB RAM). The young generation size was 100 MB (80MB for Eden,
10MB for each survivor) and the old generation size was 2,4GB.
I had the following:
* Average allocation rate: 352MB/s (outliers above 600MB/s)
* 4.5 DefNew cycles per second
* 1 CMS cycle every 10 minutes
Therefore, during the test, Cassandra was promoting objects at a rate of
3,8MB/s.
I think the size of Eden could be determined mostly by the allocation rate and
the DefNew/ParNew frequency we want to achieve. Here, for instance, I would
rather have had a bigger young generation to have ~1 DefNew cycle/s.
I did not enable {{-XX:+PrintTenuringDistribution}} so I do not know whether
the objects were prematurely promoted. That would have given pointers on
survivors sizing as well.
Do you have any gc logs with such flag ?
> Revaluate Default JVM tuning parameters
> ---------------------------------------
>
> 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
> Attachments: upload.png
>
>
> 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)
