cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-11226) nodetool tablestats' keyspace-level metrics are wrong/misleading
Date Thu, 17 Mar 2016 11:36:33 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-11226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne updated CASSANDRA-11226:
-----------------------------------------
    Status: Patch Available  (was: Open)

Patch is [here|https://github.com/pcmanus/cassandra/commits/11226]. I went with option 2:
we don't really support humongous amounts of tables in the first place and as you said, it's
not a performance sensible tool in the first place. Plus, while this might maybe be improvement,
the current implementation iterates over all tables of all keyspaces no matter what ends up
being displayed, so it's not like this patch will have any performance impact on the status
quo.

I took the liberty to do a few cleanups while at it btw. And the patch is against trunk: not
convinced it's worth backporting given that it's been the way it is forever and that in theory
changing the numbers in a minor/bug fix release feels not nice.

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

Mime
View raw message