Jean,
What does your cfstats look like? Especially "SSTables in each level" line.
On Wed, Feb 10, 2016 at 8:33 AM, Jean Carlo <jean.jeancar...@gmail.com>
wrote:
> Hello guys!
>
> I am testing the repair inc in my custer cassandra. I am doing my test
> over these tables
>
> *CREATE TABLE pns_nonreg_bench.cf3* (
> s text,
> sp int,
> d text,
> dp int,
> m map<text, text>,
> t timestamp,
> PRIMARY KEY (s, sp, d, dp)
> ) WITH CLUSTERING ORDER BY (sp ASC, d ASC, dp ASC)
>
> AND compaction = {'class': 'org.apache.cassandra.db.compaction.
> *LeveledCompactionStrategy*'}
> AND compression = {'sstable_compression':
> 'org.apache.cassandra.io.compress.*SnappyCompressor*'}
>
> *CREATE TABLE pns_nonreg_bench.cf1* (
> ise text PRIMARY KEY,
> int_col int,
> text_col text,
> ts_col timestamp,
> uuid_col uuid
> ) WITH bloom_filter_fp_chance = 0.01
> AND compaction = {'class': 'org.apache.cassandra.db.compaction.
> *LeveledCompactionStrategy*'}
> AND compression = {'sstable_compression':
> 'org.apache.cassandra.io.compress.*SnappyCompressor*'}
>
>
>
> *table cf1 Space used (live): 665.7 MB*
>
> *table cf2*
> * Space used (live): 697.03 MB*
>
> It happens that when I do repair -inc -par on theses tables, *cf2 got a
> pick of 3k sstables*. When the repair finish, it takes 30 min or more to
> finish all the compactations and return to 6 sstable.
>
> I am a little concern about if this will happen on production. is it
> normal?
>
> Saludos
>
> Jean Carlo
>
> "The best way to predict the future is to invent it" Alan Kay
>
