On Wed, Jul 7, 2010 at 1:22 PM, Julie <julie.su...@nextcentury.com> wrote: > Jonathan Ellis <jbellis <at> gmail.com> writes: > >> On Wed, Jul 7, 2010 at 12:10 PM, Julie <julie.sugar <at> nextcentury.com> > wrote: >> > >> > This doesn't explain why 30 GB of data is taking up 106 GB of disk 24 hours >> > after all writes have completed. Compactions should be complete, no? >> >> http://wiki.apache.org/cassandra/MemtableSSTable should help. > > Thank you for your response, Jonathan. I may be misunderstanding the page you > referred me to. Does it say I can expect that I will have temporary periods > when 2x my existing data size will be required for disk space? This I can > plan > for.
Yes, it does, but I was primarily referring to these paragraphs: "SSTables that are obsoleted by a compaction are deleted asynchronously when the JVM performs a GC. You can force a GC from jconsole if necessary, but Cassandra will force one itself if it detects that it is low on space. A compaction marker is also added to obsolete sstables so they can be deleted on startup if the server does not perform a GC before being restarted. "CFStoreMBean exposes sstable space used as getLiveDiskSpaceUsed (only includes size of non-obsolete files) and getTotalDiskSpaceUsed (includes everything)." -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
