By default Cassandra uses 1/3rd heap size for memtable storage. If you make sure memtables smaller they should flush faster and you commit logs should not grow large.
Large commit logs are not a problem, some use cases that write to some Column Families more then other can make the commit log directory grow. Basically the commit log does not get removed until everything in it is flushed. We have a nagios alarm on ours, if it hits 8GB something is wrong, but again large commit log is normal and I would not worry. Edward On Wed, Jan 23, 2013 at 10:42 AM, vhmolinar <vhmoli...@gmail.com> wrote: > Hi fellows. > I current have 3 nodes cluster running with a replication factor of 1. > It's a pretty simple deployment and all my enforcements are focused in > writes rather than reads. > Actually I'm noticing that my commit log size is always very big if > compared > to the ammout of data being persisted(which varies on 5gb). > > So, that lead me to three doubts: > 1- When a commit log gets bigger, does it mean that cassandra hasnt > processed yet those writes? > 2- How could I speed my flushes to sstables? > 3- Does my commit log decrease as much as my sstable increases? Is it a > rule? > > > > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Large-commit-log-reasons-tp7584964.html > Sent from the cassandra-u...@incubator.apache.org mailing list archive at > Nabble.com. >
