[
https://issues.apache.org/jira/browse/CASSANDRA-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750064#action_12750064
]
Jonathan Ellis commented on CASSANDRA-406:
------------------------------------------
so there are a couple metrics that could be useful:
- ssTables.size() -- if this is over a few dozen something is wrong
- the total size of each data directory, including filter and index files --
tells us if we're running out of space
- the average size and count of the sstables as bucketized by
getCompactionBuckets -- tells us if compaction bucketing is working as expected
These are things we can graph easily (with the possible exception of #3 -- but
that would be a cool histogram to have) and get value out of... I don't see
knowing the size of an individual sstable being valuable though.
I'm not convinced the lock counter is useful in general, but it's worth trying
out internally to see if it adds to your insight into the system. But if it
basically just mirrors read latency then I don't think we need it.
> SSTable File Metrics per CF
> ---------------------------
>
> Key: CASSANDRA-406
> URL: https://issues.apache.org/jira/browse/CASSANDRA-406
> Project: Cassandra
> Issue Type: New Feature
> Affects Versions: 0.5
> Reporter: Chris Goffinet
> Assignee: Sammy Yu
> Priority: Minor
> Fix For: 0.5
>
> Attachments:
> 0001-Expose-out-queue-length-of-sstable-lock-in-MBean-int.patch
>
>
> We should add sstable-physical-files per CF in cfstats mbean
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
