Nate,

Thanks. I dug through the changes a bit more and I believe my original
observation may have been due to:

https://github.com/krummas/cassandra/commit/fbc47e3b950949a8aa191bc7e91eb6cb396fe6a8

from: https://issues.apache.org/jira/browse/CASSANDRA-9572

I had originally passed over it because we are not using DTCS, but it
matches since the upgrade appeared to only drop fully expired sstables.


Mike

On Sat, Jul 18, 2015 at 3:40 PM, Nate McCall <n...@thelastpickle.com> wrote:

> Perhaps https://issues.apache.org/jira/browse/CASSANDRA-9592 got
> compactions moving forward for you? This would explain the drop.
>
> However, the discussion on
> https://issues.apache.org/jira/browse/CASSANDRA-9683 seems to be similar
> to what you saw and that is currently being investigated.
>
> On Fri, Jul 17, 2015 at 10:24 AM, Mike Heffner <m...@librato.com> wrote:
>
>> Hi all,
>>
>> I've been upgrading several of our rings from 2.1.6 to 2.1.8 and I've
>> noticed that after the upgrade our storage load drops significantly (I've
>> seen up to an 80% drop).
>>
>> I believe most of the data that is dropped is tombstoned (via TTL
>> expiration) and I haven't detected any data loss yet. However, can someone
>> point me to what changed between 2.1.6 and 2.1.8 that would lead to such a
>> significant drop in tombstoned data? Looking at the changelog there's
>> nothing that jumps out at me. This is a CF definition from one of the CFs
>> that had a significant drop:
>>
>> > describe measures_mid_1;
>>
>> CREATE TABLE "Metrics".measures_mid_1 (
>>     key blob,
>>     c1 int,
>>     c2 blob,
>>     c3 blob,
>>     PRIMARY KEY (key, c1, c2)
>> ) WITH COMPACT STORAGE
>>     AND CLUSTERING ORDER BY (c1 ASC, c2 ASC)
>>     AND bloom_filter_fp_chance = 0.01
>>     AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
>>     AND comment = ''
>>     AND compaction = {'class':
>> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
>>     AND compression = {'sstable_compression':
>> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>>     AND dclocal_read_repair_chance = 0.1
>>     AND default_time_to_live = 0
>>     AND gc_grace_seconds = 0
>>     AND max_index_interval = 2048
>>     AND memtable_flush_period_in_ms = 0
>>     AND min_index_interval = 128
>>     AND read_repair_chance = 0.0
>>     AND speculative_retry = '99.0PERCENTILE';
>>
>> Thanks,
>>
>> Mike
>>
>> --
>>
>>   Mike Heffner <m...@librato.com>
>>   Librato, Inc.
>>
>>
>
>
> --
> -----------------
> Nate McCall
> Austin, TX
> @zznate
>
> Co-Founder & Sr. Technical Consultant
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>



-- 

  Mike Heffner <m...@librato.com>
  Librato, Inc.

Reply via email to