[jira] [Commented] (CASSANDRA-6522) DroppableTombstoneRatio JMX value is 0.0 for all CFs

["Chris Burroughs (JIRA)" <ji...@apache.org>]

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

Chris Burroughs commented on CASSANDRA-6522:
--------------------------------------------

This a "jmx value reporting" bug or a "sstables not getting compacted" bug?

> DroppableTombstoneRatio JMX value is 0.0 for all CFs
> ----------------------------------------------------
>
>                 Key: CASSANDRA-6522
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6522
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Ubuntu 12.04 LTS, Cassandra 1.2.8
>            Reporter: Daniel Kador
>            Assignee: Marcus Eriksson
>            Priority: Minor
>             Fix For: 2.0.6
>
>         Attachments: 0001-account-for-range-and-row-tombstones-in-tombstone-dr.patch
>
>
> We're seeing that the JMX value for DroppableTombstoneRatio for all our CFs is 0.0. On the face of it that seems wrong since we've definitely issued a ton of deletes for row keys to expire some old data that we no longer need (and it definitely hasn't been reclaimed from disk yet). Am I misunderstanding what this means / how to use it? We're on 1.2.8 and using leveled compaction for all our CFs.
> gc_grace_seconds is set to 1 day and we've issued a series of deletes over a day ago, so gc_grace has elapsed.
> Cluster is 18 nodes.  Two DCs, so 9 nodes in each DC.  Each node has capacity for 1.5TB or so and is sitting with about 1TB under management.  That's why we wanted to do deletes, obviously.  Most of that 1TB is a single CF (called "events") which represents intermediate state for us that we can delete.
> Happy to provide any more info, just let me know.



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