[
https://issues.apache.org/jira/browse/CASSANDRA-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13860120#comment-13860120
]
Marcus Eriksson commented on CASSANDRA-6522:
--------------------------------------------
This metric only counts deleted columns, I guess you have been doing entire row
deletes?
[~jbellis] [~yukim] Should we try to estimate how many columns are affected by
a row/range tombstone and include in this metric?
> 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
> Priority: Minor
>
> 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)
