Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 29 Apr 2015 15:52:09 +0000 (UTC)
From: "Phil Yang (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12724781.1404237732000.22669.1430322729830@Atlassian.JIRA>
In-Reply-To: <JIRA.12724781.1404237732000@Atlassian.JIRA>
References: <JIRA.12724781.1404237732000@Atlassian.JIRA>
 <JIRA.12724781.1404237732664@arcas>
Subject: [jira] [Comment Edited] (CASSANDRA-7486) Compare CMS and G1 pause
 times
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Phil Yang edited comment on CASSANDRA-7486 at 4/29/15 3:51 PM:
---------------------------------------------------------------

I think the default option should be prudently and carefully enough to change. Usually for C* users, it is acceptable that there is no better performance in new version. However, it may be unacceptable if the new version get a worse performance. If there is risk that in some cases G1 is worse than CMS, it may be a better choice to make G1 an optional choice first by offering another conf/cassandra-env-g1.sh file to let people have a try and don't change the default settings.

For the tests comparing G1 and CMS, does the tests cover some extreme case? For example: bootstrap/rebuild/remove node, repair, lots of queries over tombstone_failure_threshold... And I think each test should take at lease 24 hours to have several full GCs to estimate the latency.

Furthermore, now using CMS, we have a max heap size (8GB) limit even if the memory of this node is very large. If we decide to change the default gc algorithm, what is the suitable new limit?


was (Author: yangzhe1991):
I think the default option should be prudence and care enough to change. Usually for C* users, it is acceptable that there is no better performance in new version. However, it may be unacceptable if the new version get a worse performance. If there is risk that in some cases G1 is worse than CMS, it may be a better choice to make G1 an optional choice first by offering another conf/cassandra-env-g1.sh file to let people have a try and don't change the default settings.

For the tests comparing G1 and CMS, does the tests cover some extreme case? For example: bootstrap/rebuild/remove node, repair, lots of queries over tombstone_failure_threshold... And I think each test should take at lease 24 hours to have several full GCs to estimate the latency.

Furthermore, now using CMS, we have a max heap size (8GB) limit even if the memory of this node is very large. If we decide to change the default gc algorithm, what is the suitable new limit?

> 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.6
>
>
> 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)