cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <>
Subject Re: System keyspace leak?
Date Wed, 04 Apr 2012 07:17:12 GMT
On Wed, Apr 4, 2012 at 3:14 AM, David Leimbach <> wrote:
> Well I just found this:
> which explains a ton...  It looks like this particular Column Family will
> grow infinitely (it's just one row with a column per migration), so if I'm
> pounding on my Cassandra node with CREATE/DROP activity, I'm going to make
> VERY wide row.
> That tells me enough to say "don't do that!"  :-)

All that is true in 1.0 but know that we've "fixed" it in the upcoming
1.1 (


> Dave
> On Tue, Apr 3, 2012 at 6:00 PM, David Leimbach <> wrote:
>> I've been trying to understand the overhead of create/drop keyspace on
>> Cassandra 1.0.8.  It's not free, especially when I've managed to drive up
>> the LiveDiskSpaceUsed for the Migrations CF in the "system" keyspace up to
>> over 12 MB of disk.
>> I've tried doing "nodetool -h localhost repair system" and other nodetool
>> commands to try to compact the SSTables involved with it, but it never wants
>> to let go of that slowly growing space.
>> The Cassandra node in question is in a ring of size 1.
>> Other than clobbering my data directory, how do I get my space back?  Is
>> it natural for this to grow seemingly infinitely (even though it's pretty
>> small increments), or did I find a bug?
>> The reason I ask is I need to run unit tests in a shared developer
>> infrastructure with Cassandra, and we were having a little trouble with
>> TRUNCATE on column families, but that might have been environmental (I've
>> not looked deeply into it).
>> Which is less expensive?  Create/Drop, or Truncate?  I don't expect
>> Truncate to swell the Migration Column Family because it tracks (seemingly)
>> schema changes.
>> Dave

View raw message