[
https://issues.apache.org/jira/browse/CASSANDRA-7486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14523146#comment-14523146
]
Benedict commented on CASSANDRA-7486:
-------------------------------------
bq. if I am reading correctly there was pretty never an old generation
collection under the workload I looked at. The old gen was growing but never
reached the point it needed to do an old gen GC.
bq. Another behavior to consider is worst case pause time when there is
fragmentation.
These are concerns we should not dismiss out of hand. My concern is that these
benchmarks in an idealised world of a steady rate of work production is not
representative of a workload including repair, validation, long running huge
compactions, hinting, periodic read/write load spikes. If these performance
profiles are dependent on the memtables never being promoted, this is dependent
on the disk keeping up, and under a worse but realistic workload the
characteristics may be nothing like what [[email protected]] is seeing.
Changing these defaults should be done with the absolute utmost of care, and I
would like to see a lot of very long running mixed workload tests including all
of the other spanners in the works.
> Compare CMS and G1 pause times
> ------------------------------
>
> Key: CASSANDRA-7486
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7486
> Project: Cassandra
> Issue Type: Test
> Components: Config
> Reporter: Jonathan Ellis
> Assignee: Shawn Kumar
> Fix For: 2.1.x
>
>
> See
> http://www.slideshare.net/MonicaBeckwith/garbage-first-garbage-collector-g1-7486gc-migration-to-expectations-and-advanced-tuning
> and https://twitter.com/rbranson/status/482113561431265281
> May want to default 2.1 to G1.
> 2.1 is a different animal from 2.0 after moving most of memtables off heap.
> Suspect this will help G1 even more than CMS. (NB this is off by default but
> needs to be part of the test.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
