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 <ken.hanc...@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 >
