[ 
https://issues.apache.org/jira/browse/CASSANDRA-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13910586#comment-13910586
 ] 

Keith Wright commented on CASSANDRA-6654:
-----------------------------------------

Happy to!  Each row is a combination of several writes due to the inability to 
set various TTLs per column via CQL3 (we are using the datastax driver).  
Whenever writing sku_time data, we ALWAYS set a TTL to 28 days and same for 
values but at 7 days.  When writing other, data we either TTL to 6 months or 
provide none (~95% would be with the 6 month TTL).  Couple of things to note:

- approximately 3 weeks ago we increased our SSTable size from 64 to 160 MB but 
we did not force a recompaction
- approximately 8 weeks ago we temporarily increased the gc_grace_seconds from 
a day to 4 weeks due to a node going down.  Approximately 3 weeks ago we reset 
the gc_grace_seconds back to 1 day.

It "feels" like the data explosion corresponds with the increase of gc grace 
seconds.  Is it possible that changing the value back is not being honored?

Thanks!!!

> Droppable tombstones are not being removed from LCS table despite being above 
> 20%
> ---------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6654
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6654
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: 1.2.13 VNodes with murmur3
>            Reporter: Keith Wright
>            Assignee: Russ Hatch
>         Attachments: Screen Shot 2014-02-05 at 9.38.20 AM.png
>
>
> JMX is showing that one of our CQL3 LCS tables has a droppable tombstone 
> ratio above 20% and increasing (currently at 28%).  Compactions are not 
> falling behind and we are using the OOTB setting for this feature so I would 
> expect not to go above 20% (will attach screen shot from JMX).   Table 
> description:
> CREATE TABLE global_user (
>   user_id timeuuid,
>   app_id int,
>   type text,
>   name text,
>   extra_param map<text, text>,
>   last timestamp,
>   paid boolean,
>   sku_time map<text, timestamp>,
>   values map<timestamp, float>,
>   PRIMARY KEY (user_id, app_id, type, name)
> ) WITH
>   bloom_filter_fp_chance=0.100000 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.000000 AND
>   gc_grace_seconds=86400 AND
>   read_repair_chance=0.100000 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   compaction={'sstable_size_in_mb': '160', 'class': 
> 'LeveledCompactionStrategy'} AND
>   compression={'chunk_length_kb': '8', 'crc_check_chance': '0.1', 
> 'sstable_compression': 'LZ4Compressor'}; 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to