[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878094#comment-16878094
]
Aleksey Yeschenko commented on CASSANDRA-14670:
---
bq. We have a followup jira already in
https://issues.apache.org/jira/browse/CASSANDRA-15194 that i can make change to
change it to be ((keyspace), table)
WFM perfectly (:
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878082#comment-16878082
]
Chris Lohfink commented on CASSANDRA-14670:
---
We have a followup jira already in
https://issues.apache.org/jira/browse/CASSANDRA-15194 that i can make change to
change it to be {{((keyspace), table)}}
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878078#comment-16878078
]
Aleksey Yeschenko commented on CASSANDRA-14670:
---
bq. If you're this passionate about having a "correct" data model, reworking
the virtual tables to be ((keyspace), table) today without ORDER BY would be a
better approach. At this this gives us the ability to write tooling around the
tables and if ORDER BY improvements make it in, great. If not, well, we still
have the data and can sort client side.
I think this would be perfectly fine, FWIW.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877921#comment-16877921
]
Chris Lohfink commented on CASSANDRA-14670:
---
I will bring up that [~slebresne] in the original virtual tables you were
arguing against removing the ALLOW FILTERING restrictions because inconsistent
modeling will confuse users. I am definitely all for letting people make any
kind of ordering or filtering on virtual tables though, just surprised that you
are now wanting opposite.
I havent really looked into what it takes to allow ORDER BY to be free for all
but if someone has an idea on that already lets open ticket then when its
complete we can fix this easily.
Lets not make operations more difficult in meantime. We talk like this is some
hard API like the protocol versions but we massively change output for
operational tools sometimes on a minor version updates (or even builds) with
nodetool, jmx, and metrics. I dont think we need to suddenly start require
major versions to change virtual tables, especially on the initial version.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877912#comment-16877912
]
Jon Haddad commented on CASSANDRA-14670:
> Personally, I'd vote for reverting this until done right, or block 4.0 on a
> follow-up ticket to fix it, but saying "there is still time before 4.0 GA" is
> the surest way to have it slip.
Do you really think this is the appropriate response? Removing a feature that
virtually every single operator would use (happily) because it has a strange
virtual data model? I've worked on hundreds of clusters and almost none of
them have correctly setup monitoring dashboards. This is one of the most
frustrating parts of Cassandra at the moment and you're suggesting we revert a
feature that makes it significantly easier to use.
If you're this passionate about having a "correct" data model, reworking the
virtual tables to be {{((keyspace), table)}} today without {{ORDER BY}} would
be a better approach. At this this gives us the ability to write tooling
around the tables and if {{ORDER BY}} improvements make it in, great. If not,
well, we still have the data and can sort client side.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877729#comment-16877729
]
Sylvain Lebresne commented on CASSANDRA-14670:
--
Fwiw, I rather strongly agree with [~iamaleksey] here. Breaking the core
foundation of data modeling for a virtual table 'because it looks at bit better
by default' is a really bad idea imo, and I even disagree that it's a better
UX, because it might actually confuse people that are not C* developers, while
using {{ORDER BY}} will be familiar to every developer on earth.
Lifting restrictions on {{ORDER BY}} and {{ALLOW FILTERING}} restrictions on
virtual tables would also be generally useful for all virtual tables, so that's
an additional motivation.
bq. I am fine with changing partition key to ((keyspace_name), table_name) once
the functionality is at least possible because finding the top tables is an
operational need thats not possible otherwise.
That bugs me, because you somewhat suggest we cannot afford to delay this to do
it right on the account that it's not _possible otherwise_, but that's pretty
disingenuous when you yourself said in the description:
bq. his can kinda be figured out with cfstats sorting and some clever bash-foo
Personally, I'd vote for reverting this until done right, or block 4.0 on a
follow-up ticket to fix it, but saying "there is still time before 4.0 GA" is
the surest way to have it slip.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877150#comment-16877150
]
Jon Haddad commented on CASSANDRA-14670:
If we're going to change {{ORDER BY}} we might as well change {{ALLOW
FILTERING}} as well, reducing friction in both cases.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877137#comment-16877137
]
Chris Lohfink commented on CASSANDRA-14670:
---
I say once the change for {{order by}} is in lets revisit and change it, its
easy enough change and until 4.0 is GA we can still change this around. I am
fine with changing partition key to {{((keyspace_name), table_name)}} once the
functionality is at least possible because finding the top tables is an
operational _need_ thats not possible otherwise.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877131#comment-16877131
]
Aleksey Yeschenko commented on CASSANDRA-14670:
---
bq. Requiring the operator to specify the ORDER BY clause is significantly
worse UX.
This is hyperbolic (: With completion in CQLSH, it's just a few extra
characters to type, but what you gain is consistency with literally every other
table, conceptual purity, and ability to narrow down easily by keyspace without
{{ALLOW FILTERING}} (although the latter isn't a big deal to me, just as
{{ORDER BY}} isn't).
For deployments with really large count of keyspaces/tables the former will
matter however.
The primary key I'd like to see for these tables would be {{((keyspace_name),
table_name)}}, for the record.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877109#comment-16877109
]
Jon Haddad commented on CASSANDRA-14670:
When I did the review on it, I had the same thought, but after changing the
code around to work differently I realized the UX is significantly better with
count as the first element of the partition key.
It doesn't make sense when you look at it from a code-first perspective but the
user interface in CQLSH is far superior than the alternative.
Having tried it both ways, I can say this is the better option. Requiring the
operator to specify the {{ORDER BY}} clause is significantly worse UX.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877071#comment-16877071
]
Aleksey Yeschenko commented on CASSANDRA-14670:
---
I'm not sure I agree. This same effect can be achieved with changes to `ORDER
BY`, without hacking in the partition key. It's more work to get right, but we
can do it later if pressed for time now. APIs, on the other hand, are 'forever'
and and shouldn't be sacrificed for expediency.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877029#comment-16877029
]
Chris Lohfink commented on CASSANDRA-14670:
---
I would say yes to giving UX a front seat for these. I don't think we need to
sacrifice usability for the sake of making it true to how it would look if it
was stored on disk if it was a real table. You can still do all the direct
querying ie: {{SELECT * FROM system_views.local_reads WHERE keyspace_name =
'system' ALLOW FILTERING}}. No functionality is lost. I currently run python
script hitting sometimes hundreds of jmx mbeans to get that view of the data
and use it regularly.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16876784#comment-16876784
]
Aleksey Yeschenko commented on CASSANDRA-14670:
---
Are you guys sure that putting `count` in the partition key is a good idea? The
partition key isn't really the right sort of place for mutable components like
this, and putting it there makes it impossible to look up by partition key. I
see the intention, but this might not be the right solution to the sorting
issue - relaxing `ORDER BY` is.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873481#comment-16873481
]
Chris Lohfink commented on CASSANDRA-14670:
---
Made recommended changes and Jon took another quick look.
Thanks, committed as
[07ff9e57344f1d837e4aef3cbca26b953745bcd7|[https://github.com/apache/cassandra/commit/07ff9e57344f1d837e4aef3cbca26b953745bcd7]].
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853314#comment-16853314
]
Jon Haddad commented on CASSANDRA-14670:
Alright, I looked over the code & went through each table. +1, with a few
nits.
* Using the abstract class to create a bunch of useful, similar views is
clever. I like it. In fact, I like this more than a single table showing
*everything*. This has nice future proofing from a client perspective.
* Can you add some general comments explaining what's happening there so it's
easier for people to grok?
* It took me a little while to understand why {{count}} was part of the
partition key. After a few minutes I realized it's to sort the table in
descending order so people are able to focus on the most active tables. Adding
something like the following will make it a little clearer why:
{noformat}
We use the count, sorted in descending order, as the partition key in order to
visually sort the rows when selecting the entire table in CQLSH.
{noformat}
Other than those minor items, +1.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853087#comment-16853087
]
Jon Haddad commented on CASSANDRA-14670:
I'll take a look at this today.
> Table Metrics Virtual Table
> ---
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> +---+
> 126934 |system | size_estimates
>9887 | system_schema |columns
>9887 | system_schema | tables
>6866 |system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> ---+---+-+---+---+-+
> 23 |system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns |126934 |126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes |219342 |219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> ---+---++--+-++
> 2 |system | local |0 | 0 | 0 | 0.005324
> 1 | system_auth | roles |0 | 0 | 0 | 0.002662
> 0 | basic | wide |0 | 0 | 0 | 0
> 0 | basic | wide3 |0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 |0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
