then obsolete sstables is not your culprit. On Thu, Jul 8, 2010 at 8:32 AM, Julie <julie.su...@nextcentury.com> wrote: > Jonathan Ellis <jbellis <at> gmail.com> writes: > >> "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)." >> > > Thank you so much for your help. > If I'm reading this right, it sounds like the extra 76 GB of disk space being > used could be due to SSTables that are obsolete due to compaction but not yet > deleted. But would I be able to see a big difference in cfstats then between > Space used (live) and Space used (total)? Here's what is being reported for > this node: > Space used (live): 113946099884 > Space used (total): 113946099884 > > > > >
-- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
