Thank you Aaron and others. That helped and we were able to limit the commitlog disk usage. We will be doing some tests by changing the memtable_total_space_in_mb param and see how that goes.
On Mon, Feb 27, 2012 at 12:51 PM, aaron morton <aa...@thelastpickle.com>wrote: > 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. >>> >>> >>> >> > >
