[
https://issues.apache.org/jira/browse/CASSANDRA-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893333#comment-13893333
]
Marcus Eriksson commented on CASSANDRA-6522:
--------------------------------------------
Both
It is the histogram used for deciding if we should do a tombstone-only
compaction that is exposed over JMX
> 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)
