[ 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)