I see, well that's what I expected, but it still should improve a read
latency, since it will reduce the number of disk seeks per row request, is
my assumption correct?
On Wed, Dec 31, 2014 at 11:51 AM, Robert Coli <rc...@eventbrite.com> wrote:
> On Wed, Dec 31, 2014 at 11:35 AM, Mikhail Strebkov <streb...@gmail.com>
> wrote:
>
>> > How effective are compactions in this CF? "grep %
>> /var/log/cassandra/system.log"?
>> I'm not sure what type of logs should I share, when I do "grep %
>> /var/log/cassandra/system.log" I don't see anything related to this
>> long-running compaction. But here is the result of this grep:
>>
>> INFO [CompactionExecutor:4] 2014-12-30 23:05:45,547
>> CompactionTask.java:251 - Compacted 22 sstables to
>> [/raid0/cassandra/data/my_keyspace/my_table-
>> 6b40d819520d35c1957008d343f23ccd/my_keyspace-my_table-ka-15759,].
>> 131,389,927 bytes to 121,512,669 (~92% of original) in 65,894ms =
>> 1.758635MB/s. 451,590 total partitions merged to 399,267. Partition merge
>> counts were {1:355582, 2:36885, 3:5419, 4:1047, 5:267, 6:35, 7:15, 8:14,
>> 9:1, 11:2, }
>>
>
> These are the lines I was asking about. The question is how much garbage a
> typical compaction removes. It seems in this CF, the answer is "not very
> much" so you can expect the result of your major compaction to be about the
> same size as input. IOW, it's most like a simple "merge" of the sstables.
>
> =Rob
>
