On Wed, Jul 7, 2010 at 1:22 PM, Julie <julie.sugar@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