The challenge that we face is that our commitlog disk capacity is much much less (under 10 GB in some cases) than the disk capacity of SSTables. So we cannot really have the commitlog data continuously growing. This is the reason that we need to be able to tune the the way we flush the memtables. >From this link - http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-improved-memory-and-disk-space-management, it looks like "commitlog_total_space_in_mb" is the parameter to control the rate at which memtables get flushed. Also it seems "memtable_total_space_in_mb" is also another setting to play with. we are planning to do some load testing with changes to these two settings, but can anyone confirm that i am headed in the right direction? Or any other pointers on this?
On Sun, Feb 26, 2012 at 5:26 PM, Mohit Anchlia <mohitanch...@gmail.com>wrote: > > > On Sun, Feb 26, 2012 at 12:18 PM, aaron morton <aa...@thelastpickle.com>wrote: > >> Nathan Milford has a post about taking a node down >> >> http://blog.milford.io/2011/11/rolling-upgrades-for-cassandra/ >> >> The only thing I would do differently would be turn off thrift first. >> >> Cheers >> > > Isn't decomission meant to do the same thing as disablethrift and gossip? > >> >> >> ----------------- >> Aaron Morton >> Freelance Developer >> @aaronmorton >> http://www.thelastpickle.com >> >> On 27/02/2012, at 4:35 AM, Edward Capriolo wrote: >> >> If you are doing a planned maintenance you can flush first as well >> ensuring the that the commit logs will not be as large. >> >> On Sun, Feb 26, 2012 at 10:09 AM, Radim Kolar <h...@sendmail.cz> wrote: >> >> if a node goes down, it will take longer for commitlog replay. >> >> >> commit log replay time is insignificant. most time during node startup is >> >> wasted on index sampling. Index sampling here runs for about 15 minutes. >> >> >> >
