Cassanda JVM GC defaults question

[Ken Hancock <ke...@schange.com>]

I'm in the process of trying to tune the GC and I'm far from an expert in
this area, so hoping someone can tell me I'm either out in left field or
on-track.

Cassandra's default GC settings are (abbreviated):
+UseConcMarkSweepGC
+CMSInitiaitingOccupancyFraction=75
+UseCMSInitiatingOccupancyOnly

Also in cassandra.yaml:
flush_largest_memtables_at: 0.75

Since the new heap is relatively small, if I'm understanding this correctly
CMS will normally not kick in until it's at roughly 75% of the heap (75% of
size-new, new being relatively small compared to the overall heap).  These
two settings being very close would seem that both trigger at nearly the
same point which might be undesirable as the flushing would also create
more GC pressure (in addition to FlushWriter blocking if multiple tables
are queued for flushing because of this).

Clearly more heap will give us more peak running room, but would also
lowering the CMSInitiatingOccupancyFraction help at the expense of some
added CPU for more frequent, smaller collections?

Mikio Bruan's blog had some interesting tests in this area....
http://blog.mikiobraun.de/2010/08/cassandra-gc-tuning.html

Re: Cassanda JVM GC defaults question

[Ken Hancock <ke...@schange.com>]

Wouldn't I want flush_largest_memtables_at larger than my
OccupyingFraction?  I want GC to kick in before I have to dump my memtables
not after.


On Wed, Apr 23, 2014 at 10:12 AM, Ruchir Jha <ru...@gmail.com> wrote:

> Lowering CMSInitiatingOccupancyFraction to less than 0.75 will lead to
> more GC interference and will impact write performance. If you're not
> sensitive to this impact, your expectation is correct, however make
> sure your flush_largest_memtables_at is always set to less than or
> equal to the occupancy fraction.
>
> On 4/23/14, Ken Hancock <ke...@schange.com> wrote:
> > I'm in the process of trying to tune the GC and I'm far from an expert in
> > this area, so hoping someone can tell me I'm either out in left field or
> > on-track.
> >
> > Cassandra's default GC settings are (abbreviated):
> > +UseConcMarkSweepGC
> > +CMSInitiaitingOccupancyFraction=75
> > +UseCMSInitiatingOccupancyOnly
> >
> > Also in cassandra.yaml:
> > flush_largest_memtables_at: 0.75
> >
> > Since the new heap is relatively small, if I'm understanding this
> correctly
> > CMS will normally not kick in until it's at roughly 75% of the heap (75%
> of
> > size-new, new being relatively small compared to the overall heap).
>  These
> > two settings being very close would seem that both trigger at nearly the
> > same point which might be undesirable as the flushing would also create
> > more GC pressure (in addition to FlushWriter blocking if multiple tables
> > are queued for flushing because of this).
> >
> > Clearly more heap will give us more peak running room, but would also
> > lowering the CMSInitiatingOccupancyFraction help at the expense of some
> > added CPU for more frequent, smaller collections?
> >
> > Mikio Bruan's blog had some interesting tests in this area....
> > http://blog.mikiobraun.de/2010/08/cassandra-gc-tuning.html
> >
>



-- 
*Ken Hancock *| System Architect, Advanced Advertising
SeaChange International
50 Nagog Park
Acton, Massachusetts 01720
ken.hancock@schange.com | www.schange.com |
NASDAQ:SEAC<http://www.schange.com/en-US/Company/InvestorRelations.aspx>

Office: +1 (978) 889-3329 | [image: Google Talk:]
ken.hancock@schange.com | [image:
Skype:]hancockks | [image: Yahoo IM:]hancockks [image:
LinkedIn]<http://www.linkedin.com/in/kenhancock>

[image: SeaChange International]
 <http://www.schange.com/>This e-mail and any attachments may contain
information which is SeaChange International confidential. The information
enclosed is intended only for the addressees herein and may not be copied
or forwarded without permission from SeaChange International.

Re: Cassanda JVM GC defaults question

[Ruchir Jha <ru...@gmail.com>]

Lowering CMSInitiatingOccupancyFraction to less than 0.75 will lead to
more GC interference and will impact write performance. If you're not
sensitive to this impact, your expectation is correct, however make
sure your flush_largest_memtables_at is always set to less than or
equal to the occupancy fraction.

On 4/23/14, Ken Hancock <ke...@schange.com> wrote:
> I'm in the process of trying to tune the GC and I'm far from an expert in
> this area, so hoping someone can tell me I'm either out in left field or
> on-track.
>
> Cassandra's default GC settings are (abbreviated):
> +UseConcMarkSweepGC
> +CMSInitiaitingOccupancyFraction=75
> +UseCMSInitiatingOccupancyOnly
>
> Also in cassandra.yaml:
> flush_largest_memtables_at: 0.75
>
> Since the new heap is relatively small, if I'm understanding this correctly
> CMS will normally not kick in until it's at roughly 75% of the heap (75% of
> size-new, new being relatively small compared to the overall heap).  These
> two settings being very close would seem that both trigger at nearly the
> same point which might be undesirable as the flushing would also create
> more GC pressure (in addition to FlushWriter blocking if multiple tables
> are queued for flushing because of this).
>
> Clearly more heap will give us more peak running room, but would also
> lowering the CMSInitiatingOccupancyFraction help at the expense of some
> added CPU for more frequent, smaller collections?
>
> Mikio Bruan's blog had some interesting tests in this area....
> http://blog.mikiobraun.de/2010/08/cassandra-gc-tuning.html
>