cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wright (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-6654) Droppable tombstones are not being removed from LCS table despite being above 20%
Date Thu, 27 Feb 2014 22:05:21 GMT

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

Keith Wright edited comment on CASSANDRA-6654 at 2/27/14 10:04 PM:
-------------------------------------------------------------------

I do.  Just wanted to help those who may see this JIRA going forward know of possible actions
to take other than waiting for 2.1.  From my point of view, given the documentation one would
expect that data with TTLs set would disappear during compactions once tombstoned.  I will
give the no-TTL a try.  Thx


was (Author: keithwrightbos):
I do.  Just wanted to help those who may see this JIRA going forward no of possible actions
to take other than waiting for 2.1.  From my point of view, given the documentation one would
expect that data with TTLs set would disappear during compactions once tombstoned.  I will
give the no-TTL a try.  Thx

> 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: Marcus Eriksson
>         Attachments: Screen Shot 2014-02-05 at 9.38.20 AM.png, dtrlog.txt, repro3.py
>
>
> 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)

Mime
View raw message