cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wei Zhu <>
Subject Re: Updated sstable size for LCS, ran upgradesstables, file sizes didn't change
Date Sat, 22 Jun 2013 00:42:47 GMT
I think the new SSTable will be in the new size. In order to do that, you need to trigger a
compaction so that the new SSTables will be generated. for LCS, there is no major compaction
though. You can run a nodetool repair and hopefully you will bring some new SSTables and compactions
will kick in. 
Or you can change the $CFName.json file under your data directory and move every SSTable to
level 0. You need to stop your node, write a simple script to alter that file and start the
node again. 

I think it will be helpful to have a nodetool command to change the SSTable Size and trigger
the rebuild of the SSTables. 


----- Original Message -----

From: "Robert Coli" <> 
Sent: Friday, June 21, 2013 4:51:29 PM 
Subject: Re: Updated sstable size for LCS, ran upgradesstables, file sizes didn't change 

On Fri, Jun 21, 2013 at 4:40 PM, Andrew Bialecki 
<> wrote: 
> However when we run alter the column 
> family and then run "nodetool upgradesstables -a keyspace columnfamily," the 
> files in the data directory have been re-written, but the file sizes are the 
> same. 
> Is this the expected behavior? If not, what's the right way to upgrade them. 
> If this is expected, how can we benchmark the read/write performance with 
> varying sstable sizes. 

It is expected, upgradesstables/scrub/clean compactions work on a 
single sstable at a time, they are not capable of combining or 
splitting them. 

In theory you could probably : 

1) start out with the largest size you want to test 
2) stop your node 
3) use sstable_split [1] to split sstables 
4) start node, test 
5) repeat 2-4 

I am not sure if there is anything about level compaction which makes 
this infeasible. 


View raw message