cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Morton <>
Subject Re: Cassandra mad GC
Date Fri, 17 Jan 2014 04:28:23 GMT
> c3.4xlarge
long par new on a machine like this is not normal. 

Do you have a custom comparator or are you using triggers ?
Do you have a data model that creates a lot of tombstones ? 

Try to return the settings to default and then tune from there, that includes returning to
the default JVM GC settings. If for no other reason than other people will be able to offer
Have you changed the compaction_throughput ? Put it back if you have. 
If you have enabled multi_threaded compaction disable it. 
Consider setting concurrent_compactors to 4 or 8 to reduce compaction churn. 
If you have increased in_memory_compaction_limit put it back.

> Cassandra logs
Can you provide some of the log messages from GCInspector ? How long are the pauses ? Is there
a lot of CMS or ParNew ? 
Do you have monitoring in place ? Is CMS able to return the heap to a low value e.g. <
3Gb ? 

> cpu load > 1000% 
Is this all from cassandra ? 
try jvmtop ( to see what cassandra threads are doing. 

It’s a lot easier to tune a system with fewer non default settings. 


Aaron Morton
New Zealand

Co-Founder & Principal Consultant
Apache Cassandra Consulting

On 16/01/2014, at 8:22 am, Arya Goudarzi <> wrote:

> It is not a good idea to change settings without identifying the root cause. Chances
are what you did masked the problem a bit for you, but the problem is still there, isn't it?
> On Wed, Jan 15, 2014 at 1:11 AM, Dimetrio <> wrote:
> I set G1 because GS started to work wrong(dropped messages) with standard GC
> settings.
> In my opinion, Cassandra started to work more stable with G1 (it's getting
> less count of timeouts now) but it's not ideally yet.
> I just want cassandra  to works fine.
> --
> View this message in context:
> Sent from the mailing list archive at
> -- 
> Cheers,
> -Arya

View raw message