yes, reducing commitlog_total_space_in_mb will reduce the amount of space needed by the commit logs.
> memtable_total_space_in_mb controls how often sstables are flushed to disk, this does not really affect the commit log. Other than the fact that a commit log segment cannot be deleted until the changes in the sstable have been flushed. But commitlog_total_space_in_mb is the correct way to control that. Hope that helps. ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 27/02/2012, at 4:48 PM, Xaero S wrote: > > 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. > > >
