On 3/13/2011 9:27 PM, aaron morton wrote:
The CF Stats are reporting you have 70GB total space taken up by
SSTables, of which 55GB is live. The rest is available for deletion,
AFAIK this happens when cassandra detects free space is running low.
I've never dug into how/when this happens though.
If there was a way to force this deletion it would be nice.
du -hs data/
78G data/
With that amount of data it seems odd to fill a 300GB space during
repair or compaction. Some thoughts:
I maybe have 50 to 100GB of other stuff including mysql and the OS
(RHEL 5.5). So about 200GB for cassandra
- What version are you using ? There were issues in early 0.7 that
resulted in a lot of temp files been left around.
0.7.3
- Take a look on disk. In the commit log directory are there a lot of
files hanging around? In the data directory for your keyspace do you
have any snapshots ? Is there anything in the saved caches directory?
No snapshots and not much other stuff
du -h saved_caches/
52K saved_caches/
du -h commitlog/
218M commitlog/
no snapshots
- When you've ran out of space what did the data directory look like ?
How did you fix the issue?
data directory had nearly 200GB of stuff. When i kill and restart the
cassandra process data dir goes down to 60GB or so. I can do the same
if i do a "Force GC" in jconsole. A few days ago i asked if anyone
knew how to force the GC in a cron job and got no response.
http://wiki.apache.org/cassandra/FAQ#cleaning_compacted_tables
After compaction is done I have lots of extra SSTables laying around and
it seems the only way to get rid of them is restarting cassandra, or
jconsole GC. I'd like a better way to automate it than restarting
cassandra.
If at all possible I'd like to somehow be able to cleanup these files
without paying for more storage of files I don't need.
Thanks,
Karl
