Hello Horschi,
Yes I understand. Thx!!!!
Best regards
Jean Carlo
"The best way to predict the future is to invent it" Alan Kay
On Wed, Feb 10, 2016 at 3:00 PM, horschi <hors...@gmail.com> wrote:
> btw: I am not saying incremental Repair in 2.1 is broken, but ... ;-)
>
> On Wed, Feb 10, 2016 at 2:59 PM, horschi <hors...@gmail.com> wrote:
> > Hi Jean,
> >
> > we had the same issue, but on SizeTieredCompaction. During repair the
> > number of SSTables and pending compactions were exploding.
> >
> > It not only affected latencies, at some point Cassandra ran out of heap.
> >
> > After the upgrade to 2.2 things got much better.
> >
> > regards,
> > Christian
> >
> >
> > On Wed, Feb 10, 2016 at 2:46 PM, Jean Carlo <jean.jeancar...@gmail.com>
> wrote:
> >> Hi Horschi !!!
> >>
> >> I have the 2.1.12. But I think it is something related to Level
> compaction
> >> strategy. It is impressive that we passed from 6 sstables to 3k sstable.
> >> I think this will affect the latency on production because the number of
> >> compactions going on
> >>
> >>
> >>
> >> Best regards
> >>
> >> Jean Carlo
> >>
> >> "The best way to predict the future is to invent it" Alan Kay
> >>
> >> On Wed, Feb 10, 2016 at 2:37 PM, horschi <hors...@gmail.com> wrote:
> >>>
> >>> Hi Jean,
> >>>
> >>> which Cassandra version do you use?
> >>>
> >>> Incremental repair got much better in 2.2 (for us at least).
> >>>
> >>> kind regards,
> >>> Christian
> >>>
> >>> On Wed, Feb 10, 2016 at 2:33 PM, 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
> >>
> >>
>
