[
https://issues.apache.org/jira/browse/CASSANDRA-11226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne reassigned CASSANDRA-11226:
--------------------------------------------
Assignee: Sylvain Lebresne
> nodetool tablestats' keyspace-level metrics are wrong/misleading
> ----------------------------------------------------------------
>
> Key: CASSANDRA-11226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11226
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Reporter: Tyler Hobbs
> Assignee: Sylvain Lebresne
> Priority: Minor
> Labels: lhf
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> In the nodetool tablestats output (formerly cfstats), we display "keyspace"
> level metrics before the table-level metrics:
> {noformat}
> Keyspace: testks
> Read Count: 14772528
> Read Latency: 0.14456651623879135 ms.
> Write Count: 4761283
> Write Latency: 0.062120404521218336 ms.
> Pending Flushes: 0
> Table: processes
> SSTable count: 7
> Space used (live): 496.76 MB
> Space used (total): 496.76 MB
> Space used by snapshots (total): 0 bytes
> Off heap memory used (total): 285.76 KB
> SSTable Compression Ratio: 0.2318241570710227
> Number of keys (estimate): 3027
> Memtable cell count: 2140
> Memtable data size: 1.66 MB
> Memtable off heap memory used: 0 bytes
> Memtable switch count: 967
> Local read count: 14772528
> Local read latency: 0.159 ms
> Local write count: 4761283
> Local write latency: 0.068 ms
> {noformat}
> However, the keyspace-level metrics are misleading, at best. They are
> aggregate metrics for every table in the keyspace _that is included in the
> command line filters_. So, if you run {{tablestats}} for a single table, the
> keyspace-level stats will only reflect that table's stats.
> I see two possible fixes:
> # If the command line options don't include the entire keyspace, skip the
> keyspace-level stats
> # Ignore the command line options, and always make the keyspace-level stats
> an aggregate of all tables in the keyspace
> My only concern with option 2 is that performance may suffer a bit on
> keyspaces with many tables. However, this is a command line tool, so as long
> as the response time is reasonable, I don't think it's a big deal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
