Sounds very odd. Is read performance degrading _after_ repair and compactions that normally result have completed ? What Compaction Strategy ? What OS and JVM ?
What are are the bloom filter false positive stats from cf stats ? Do you have some read latency numbers from cfstats ? Also, could you take a look at cfhistograms ? Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 26/09/2012, at 3:05 AM, Charles Brophy <cbro...@zulily.com> wrote: > Hey guys, > > I've begun to notice that read operations take a performance nose-dive after > a standard (full) repair of a fairly large column family: ~11 million > records. Interestingly, I've then noticed that read performance returns to > normal after a full scrub of the column family. Is it possible that the > repair operation is not correctly establishing the bloom filter afterwards? > I've noticed an interesting note of the scrub operation is that it will > "rebuild sstables with correct bloom filters" which is what is leading me to > this conclusion. Does this make sense? > > I'm using 1.1.3 and Oracle JDK 1.6.31 > The column family is a stanard type and I've noticed this exact behavior > regardless of the key/column/value serializers in use. > > Charles
