Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 16 Apr 2015 06:12:01 +0000 (UTC)
From: "Albert P Tobey (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12724781.1404237732000.16636.1429164721433@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=14497603#comment-14497603 ] 

Albert P Tobey edited comment on CASSANDRA-7486 at 4/16/15 6:11 AM:
--------------------------------------------------------------------

My benchmarks completed. These were run on 6 quad-core Intel NUCs with 16GB RAM / 240GB SSD / gigabit ethernet. The CPUs are fairly slow at 1.3Ghz i5-4250U. Cassandra 2.1.4 / Oracle JDK 8u40 / CoreOS 647.0.0 / Linux 3.19.3 (bare metal - no container). The tests were automated with a complete cluster rebuild between tests and caches dropped before starting Cassandra each time.

The big win with G1 IMO is that it is auto-tuning. I've been running it on a few other kinds of machines and it generally does much better with more CPU power.

cassandra-stress was run with an increased heap but is otherwise unmodified from Cassandra 2.1.4. I checked the gc log regularly and did not see many pauses for stress itself above 1ms here & there, with most pauses in the ~300usec range. The three stress nodes I had available are all quad-cores: i7-2600/3.4Ghz/8GB, Xeon-E31270/3.4Ghz/16GB, i5-4250U/1.3Ghz/16GB.

These were saturation tests. In all but the G1 @ 256MB test the stress runs were stable and the systems' CPUs were at 100% pretty much the whole time. The numbers smooth out a lot for all of the combinations of GC settings at more pedestrian throughput. I will kick that off when I get a chance, which will be ~2 weeks from now.

The final output of the stress is available here:

https://docs.google.com/a/datastax.com/spreadsheets/d/19Eb7HGkd5rFUD_C0ZALbK6-R4fPF9vJRr8BrvxBwo38/edit?usp=sharing
http://tobert.org/downloads/cassandra-2.1-cms-vs-g1.csv

The stress commands, system.log, GC logs, conf directory from all the servers, and full stress logs are available on my webserver here:

http://tobert.org/downloads/cassandra-2.1-cms-vs-g1-data.tar.gz (35MB)


was (Author: atobey@datastax.com):
My benchmarks completed. These were run on 6 quad-core Intel NUCs with 16GB RAM / 240GB SSD / gigabit ethernet. The CPUs are fairly slow at 1.3Ghz i5-4250U. Cassandra 2.1.4 / Oracle JDK 8u40 / CoreOS 647.0.0 / Linux 3.19.3 (bare metal - no container). The tests were automated with a complete cluster rebuild between tests and caches dropped before starting Cassandra each time.

The big win with G1 IMO is that it is auto-tuning. I've been running it on a few other kinds of machines and it generally does much better with more CPU power.

cassandra-stress was run with an increased heap but is otherwise unmodified from Cassandra 2.1.4. I checked the gc log regularly and did not see many pauses for stress itself above 1ms here & there, with most pauses in the ~300usec range. The three stress nodes I had available are all quad-cores: i7-2600/3.4Ghz/8GB, Xeon-E31270/3.4Ghz/16GB, i5-4250U/1.3Ghz/16GB.

The final output of the stress is available here:

https://docs.google.com/a/datastax.com/spreadsheets/d/19Eb7HGkd5rFUD_C0ZALbK6-R4fPF9vJRr8BrvxBwo38/edit?usp=sharing
http://tobert.org/downloads/cassandra-2.1-cms-vs-g1.csv

The stress commands, system.log, GC logs, conf directory from all the servers, and full stress logs are available on my webserver here:

http://tobert.org/downloads/cassandra-2.1-cms-vs-g1-data.tar.gz (35MB)


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