incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Schuller <>
Subject Re: JVM 7, Cass 1.1.1 and G1 garbage collector
Date Sat, 15 Sep 2012 18:24:06 GMT
> Generally tuning the garbage collector is a waste of time.

Sorry, that's BS. It can be absolutely critical, when done right, and
only "useless" when done wrong. There's a spectrum in between.

> Just follow
> someone else's recommendation and use that.

No, don't.

Most recommendations out there are completely useless in the general
case because someone did some very specific benchmark under very
specific circumstances and then recommends some particular combination
of options. In order to understand whether a particular recommendation
applies to you, you need to know enough about your use-case that I
suspect you're better of just reading up on the available options and
figuring things out. Of course, randomly trying various different
settings to see which seems to work well may be realistic - but you
loose predictability (in the face of changing patterns of traffic for
example) if you don't know why it's behaving like it is.

If you care about GC related behavior you want to understand how the
application behaves, how the garbage collector behaves, what your
requirements are, and select settings based on those requirements and
how the application and GC behavior combine to produce emergent
behavior. The "best" GC options may vary *wildly* depending on the
nature of your cluster and your goals. There are also non-GC settings
(in the specific case of Cassandra) that affect the interaction with
the garbage collector, like whether you're using row/key caching, or
things like phi conviction threshold and/or timeouts. It's very hard
for anyone to give generalized recommendations. If it weren't,
Cassandra would ship with The One True set of settings that are always
the best and there would be no discussion.

It's very unfortunate that the state of GC in the freely available
JVM:s is at this point given that there exists known and working
algorithms (and at least one practical implementation) that avoids it,
mostly. But, it's the situation we're in. The only way around it that
I know of if you're on Hotspot, is to have the application behave in
such a way that it avoids the causes of un-predictable behavior w.r.t.
GC by being careful about it's memory allocation and *retention*
profile. For the specific case of avoiding *ever* seeing a full gc, it
gets even more complex.

/ Peter Schuller (@scode,

View raw message