cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7486) Migrate to G1GC by default
Date Sun, 20 Sep 2015 13:45:07 GMT


Benedict commented on CASSANDRA-7486:


[here is one|]
10x larger
and another 100x larger [is still running|]

Interestingly, the completed 10x larger is a more nuanced picture, but this is because CMS
got slower for one of the runs, not G1GC faster - but it never got up to its prior speed -
this is weird, since 2.2 did manage to get up to its faster speed still, so there may be something
funny going on on that particular test.

bq. It seems that the max heap is still 8G in trunk so maybe it is unfair for G1. What is
the heap size of these tests?

I'm not sure I would call that unfair. These boxes have no more than 64Gb of RAM, I'm pretty
sure (perhaps only 32Gb), and so for anything but the most write-heavy workloads an 8Gb heap
is probably what you'll want to ensure the file cache can make meaningful contributions to
performance. Certainly we can and should test more scenarios, but this is a pretty typical
setup for a pretty typical piece of hardware. We should consider giving users profiles for
different workloads, though, and consider raising the max heap much higher for write-heavy
workloads, or boxes with gigantic banks of RAM, and use G1 accordingly (as driven by our research)

> Migrate to G1GC by default
> --------------------------
>                 Key: CASSANDRA-7486
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Config
>            Reporter: Jonathan Ellis
>             Fix For: 3.0 alpha 1
> See
> 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

View raw message