You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Patrick Bannister (JIRA)" <ji...@apache.org> on 2018/03/23 00:47:00 UTC
[jira] [Commented] (CASSANDRA-13889) cfstats should take sorting
and limit parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-13889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410632#comment-16410632 ]
Patrick Bannister commented on CASSANDRA-13889:
-----------------------------------------------
Jon, are you thinking that the output would remain in one of its current output forms - text, json, or yaml - but sorted and truncated according to the options provided by the user?
To sort, the user would have to provide a command line argument indicating which metric is the sorting key - something like --sort "read count".
I think sorting would default to descending, with an optional argument to indicate an ascending sort (probably --ascending). Actually it's not clear to me that any of these metrics would be interesting sorted ascending, except maybe compression ratio, but I'd defer on that question to somebody with more experience troubleshooting production clusters, and in any case the implementation of an optional ascending sort would not be difficult
Is there a compelling use case for a complex sort, for example, sort first by write latency descending, then by write count descending, then by memtable off heap memory used descending?
If a user wants the top K tables, that implies they must also specify a sort key.
Currently we output some overall metrics for keyspaces before outputting table-specific metrics for that keyspace. If a user requests sorting or top K tables, with more than one keyspace or without specifying anything, what do we do with the keyspace metrics? Would we just omit the keyspace metrics from the output?
> cfstats should take sorting and limit parameters
> ------------------------------------------------
>
> Key: CASSANDRA-13889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13889
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Jon Haddad
> Priority: Major
> Fix For: 4.0
>
>
> When looking at a problematic node I'm not familiar with, one of the first things I do is check cfstats to identify the tables with the most reads, writes, and data. This is fine as long as there aren't a lot of tables but once it goes above a dozen it's quite difficult. cfstats should allow me to sort the results and limit to top K tables.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org