[jira] [Updated] (CASSANDRA-15200) Can a new adding node store other keyspaces' data and add permission of one more machine failure for a replicator 2's keyspace in the new even number nodes' DC
[ https://issues.apache.org/jira/browse/CASSANDRA-15200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-15200: --- Resolution: Not A Problem Status: Resolved (was: Triage Needed) JIRA is for bug reports and feature discussion, not questions and answers. > Can a new adding node store other keyspaces' data and add permission of > one more machine failure for a replicator 2's keyspace in the new even number > nodes' DC? > -- > > Key: CASSANDRA-15200 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15200 > Project: Cassandra > Issue Type: Improvement >Reporter: gloCalHelp.com >Priority: Normal > > Question on adding a new node, replicator and how many machine failes? > Can a new adding node store other keyspaces' data and add permission of > one more machine failure for a replicator 2's keyspace in the new even number > nodes' DC? > Cassandra's designing of adding a new node for only a keyspace is > quite good for a high load keyspace and token allocation. But I have > aquestions: > 1st, if the high load keyspace has a replicator of only 2, and > original cluster has only 3 datanodes, if adding a new node to form a 4 > datanodes for this keyspace, then there will permit how many machine failes > for this 2 replicator keyspace's 4 data nodes center? > 2nd, on cassandra's official web, there is a line of : To use this > approach, the new node must be started with the JVM option > -Dcassandra.allocate_tokens_for_keyspace=, where is the > keyspace from which the algorithm can find the load information to optimize > token assignment for. > Does this mean that a new adding node can only store a keyspace's data? > > -- 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] [Created] (CASSANDRA-15200) Can a new adding node store other keyspaces' data and add permission of one more machine failure for a replicator 2's keyspace in the new even number nodes' DC
gloCalHelp.com created CASSANDRA-15200: -- Summary: Can a new adding node store other keyspaces' data and add permission of one more machine failure for a replicator 2's keyspace in the new even number nodes' DC? Key: CASSANDRA-15200 URL: https://issues.apache.org/jira/browse/CASSANDRA-15200 Project: Cassandra Issue Type: Improvement Reporter: gloCalHelp.com Question on adding a new node, replicator and how many machine failes? Can a new adding node store other keyspaces' data and add permission of one more machine failure for a replicator 2's keyspace in the new even number nodes' DC? Cassandra's designing of adding a new node for only a keyspace is quite good for a high load keyspace and token allocation. But I have aquestions: 1st, if the high load keyspace has a replicator of only 2, and original cluster has only 3 datanodes, if adding a new node to form a 4 datanodes for this keyspace, then there will permit how many machine failes for this 2 replicator keyspace's 4 data nodes center? 2nd, on cassandra's official web, there is a line of : To use this approach, the new node must be started with the JVM option -Dcassandra.allocate_tokens_for_keyspace=, where is the keyspace from which the algorithm can find the load information to optimize token assignment for. Does this mean that a new adding node can only store a keyspace's data? -- 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] [Updated] (CASSANDRA-15199) Cassandra throwing occasional NPE 3.11.x
[ https://issues.apache.org/jira/browse/CASSANDRA-15199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Justus updated CASSANDRA-15199: -- Description: Hey folks, decided to raise an official Jira(never done one of these before) about an issue we have found between Kong API Gateway leveraging Cassandra as our db. We run a C* cluster in 2 close DCs, 6 C* nodes total, 3 in each DC. Data replicated across all nodes. We have found C* sometimes throws NPEs based on the calls made by the lua-cassandra driver Kong leverages([https://github.com/thibaultcha/lua-cassandra]). Very specifically it seems to occur when attempting to do paging across multiple C* nodes. When persistently paging to a single C* node we can't reproduce NPEs in C*. The exact Error C* throws with its stack-trace can be seen here: [https://github.com/Kong/kong/issues/4194#issuecomment-497572751] And again when we tried to upgrade from 3.11.2 to 3.11.4 in hopes it was already resolved: [https://github.com/Kong/kong/issues/4194#issuecomment-497590235] Same error same line numbers, so code must be same in this portion. Sample of our C* Config: [https://github.com/Kong/kong/issues/4194#issuecomment-497595766] We discussed this in the ASF Slack flow as well: ASF Slack discussion ([https://the-asf.slack.com/archives/CJZLTM05A/p1559321422028200] ) Some of the more important technical comments I saw people posting here: [https://github.com/Kong/kong/issues/4194#issuecomment-497858824] I am not a C* DBA so I don't have an exact repro for you other than stating what the client application was attempting to do(Paging across multiple C* nodes within a DC) when we could see the failures. Any Apache C* folk think they see the issue or could drop me C* JAR with extra debugging print statements I could run in dev to help feed you more info? Or if you see the problem and can one shot a fix so no more NPE and Cassandra responds appropriately to the client with some sort of error message around what was wrong that would be insightful. Thanks! was: Hey folks, decided to raise an official Jira(never done one of these before) about an issue we have found between Kong API Gateway leveraging Cassandra as our db. We run a C* cluster in 2 close DCs, 6 C* nodes total, 3 in each DC. Data replicated across all nodes. We have found C* sometimes throws NPEs based on the calls made by the lua-cassandra driver Kong leverages([https://github.com/thibaultcha/lua-cassandra]). Very specifically it seems to occur when attempting to do paging across multiple C* nodes. When persistently paging to a single C* node we can't reproduce NPEs in C*. The exact Error C* throws with its stack-trace can be seen here: [https://github.com/Kong/kong/issues/4194#issuecomment-497572751] And again when we tried to upgrade from 3.11.2 to 3.11.4 in hopes it was already resolved: [https://github.com/Kong/kong/issues/4194#issuecomment-497590235] Same error same line numbers, so code must be same in this portion. Sample of our C* Config: [https://github.com/Kong/kong/issues/4194#issuecomment-497595766] We discussed this in the ASF Slack flow as well: ASF Slack discussion ([https://the-asf.slack.com/archives/CJZLTM05A/p1559321422028200] ) Some of the more important technical comments I saw people posting here: [https://github.com/Kong/kong/issues/4194#issuecomment-497858824] I am not a C* DBA so I don't have an exact repro for you other than stating what the client application was attempting to do(Paging across multiple C* nodes within a DC) when we could see the failures. Any Apache C* folk think they see the issue or could drop me C* JAR with extra debugging print statements I could run in dev to help feed you more info? Or if you see the problem and can one shot a fix so no more NPE and Cassandra responds appropriately to the client with some sort of error message around what was wrong that would be helpful. > Cassandra throwing occasional NPE 3.11.x > > > Key: CASSANDRA-15199 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15199 > Project: Cassandra > Issue Type: Bug >Reporter: Jeremy Justus >Priority: Normal > > Hey folks, decided to raise an official Jira(never done one of these before) > about an issue we have found between Kong API Gateway leveraging Cassandra as > our db. > We run a C* cluster in 2 close DCs, 6 C* nodes total, 3 in each DC. Data > replicated across all nodes. We have found C* sometimes throws NPEs based on > the calls made by the lua-cassandra driver Kong > leverages([https://github.com/thibaultcha/lua-cassandra]). Very specifically > it seems to occur when attempting to do paging across multiple C* nodes. When > persistently paging to a single C* node we can't reproduce NPEs in C*. > The exact
[jira] [Commented] (CASSANDRA-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878177#comment-16878177
]
Jon Haddad commented on CASSANDRA-15194:
rows_scanned_per_query is more obvious to beginners, I prefer that.
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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] [Created] (CASSANDRA-15199) Cassandra throwing occasional NPE 3.11.x
Jeremy Justus created CASSANDRA-15199: - Summary: Cassandra throwing occasional NPE 3.11.x Key: CASSANDRA-15199 URL: https://issues.apache.org/jira/browse/CASSANDRA-15199 Project: Cassandra Issue Type: Bug Reporter: Jeremy Justus Hey folks, decided to raise an official Jira(never done one of these before) about an issue we have found between Kong API Gateway leveraging Cassandra as our db. We run a C* cluster in 2 close DCs, 6 C* nodes total, 3 in each DC. Data replicated across all nodes. We have found C* sometimes throws NPEs based on the calls made by the lua-cassandra driver Kong leverages([https://github.com/thibaultcha/lua-cassandra]). Very specifically it seems to occur when attempting to do paging across multiple C* nodes. When persistently paging to a single C* node we can't reproduce NPEs in C*. The exact Error C* throws with its stack-trace can be seen here: [https://github.com/Kong/kong/issues/4194#issuecomment-497572751] And again when we tried to upgrade from 3.11.2 to 3.11.4 in hopes it was already resolved: [https://github.com/Kong/kong/issues/4194#issuecomment-497590235] Same error same line numbers, so code must be same in this portion. Sample of our C* Config: [https://github.com/Kong/kong/issues/4194#issuecomment-497595766] We discussed this in the ASF Slack flow as well: ASF Slack discussion ([https://the-asf.slack.com/archives/CJZLTM05A/p1559321422028200] ) Some of the more important technical comments I saw people posting here: [https://github.com/Kong/kong/issues/4194#issuecomment-497858824] I am not a C* DBA so I don't have an exact repro for you other than stating what the client application was attempting to do(Paging across multiple C* nodes within a DC) when we could see the failures. Any Apache C* folk think they see the issue or could drop me C* JAR with extra debugging print statements I could run in dev to help feed you more info? Or if you see the problem and can one shot a fix so no more NPE and Cassandra responds appropriately to the client with some sort of error message around what was wrong that would be helpful. -- 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] [Comment Edited] (CASSANDRA-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878101#comment-16878101
]
Chris Lohfink edited comment on CASSANDRA-15194 at 7/3/19 9:34 PM:
---
table naming changes sound good, I'll include them in patch. For now i think we
can stick with "mebibytes" and if theres ever a table thats not obvious what it
means that one can have special naming for it.
thinking {{live_rows_scanned}}, {{rows_scanned_per_query}}?
was (Author: cnlwsu):
table naming changes sound good, I'll include them in patch. For now i think we
can stick with "mebibytes" and if theres ever a table thats not obvious what it
means that one can have special naming for it.
thinking {{live_rows_scanned}}?
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Description: Tracks evaluating a 192 node cluster with compression and encryption on. First test is a read scaling test [https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] |Test Setup| | |Baseline|3.0.19 @d7d00036| |Candiate|trunk @abb0e177| | | | |Workload| | |Write size|4kb random| |Read size|4kb random| |Per Node Data|110GiB| |Generator|ndbench| |Key Distribution|Uniform| |SSTable Compr|Off| |Internode TLS|On (jdk)| |Internode Compr|On| |Compaction|LCS (320 MiB)| |Repair|Off| | | | |Hardware| | |Instance Type|i3.xlarge| |Deployment|96 us-east-1, 96 eu-west-1| |Region node count|96| | | | |OS Settings| | |IO scheduler|kyber| |Net qdisc|tc-fq| |readahead|32kb| |Java Version|OpenJDK 1.8.0_202 (Zulu)| | | | Second test is a [write scaling test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: was: Tracks evaluating a 192 node cluster with compression and encryption on. Test setup at (reproduced below) [https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] |Test Setup| | |Baseline|3.0.19 @d7d00036| |Candiate|trunk @abb0e177| | | | |Workload| | |Write size|4kb random| |Read size|4kb random| |Per Node Data|110GiB| |Generator|ndbench| |Key Distribution|Uniform| |SSTable Compr|Off| |Internode TLS|On (jdk)| |Internode Compr|On| |Compaction|LCS (320 MiB)| |Repair|Off| | | | |Hardware| | |Instance Type|i3.xlarge| |Deployment|96 us-east-1, 96 eu-west-1| |Region node count|96| | | | |OS Settings| | |IO scheduler|kyber| |Net qdisc|tc-fq| |readahead|32kb| |Java Version|OpenJDK 1.8.0_202 (Zulu)| | | | > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > odd_netty_jdk_tls_cpu_usage.png, trunk_14400cRPS-14400cWPS.svg, > trunk_187000cRPS-14400cWPS.svg, trunk_187kcRPS_14kcWPS.png, > trunk_22000cRPS-14400cWPS-jdk.svg, trunk_22000cRPS-14400cWPS-openssl.svg, > trunk_220kcRPS_14kcWPS.png, trunk_252kcRPS-14kcWPS.png, > trunk_93500cRPS-14400cWPS.svg, trunk_LQ_14400cRPS-14400cWPS.svg, > trunk_LQ_21600cRPS-14400cWPS.svg, trunk_Q_21600cRPS-7200cWPS.svg, > trunk_allocation_Q_21k_cRPS.svg, trunk_vs_30x_125kcRPS_14kcWPS.png, > trunk_vs_30x_14kRPS_14kcWPS_load.png, trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > First test is a read scaling test > [https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | > Second test is a [write scaling > test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: -- 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] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Description: Tracks evaluating a 192 node cluster with compression and encryption on. First test is a [read scaling test |https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] |Test Setup| | |Baseline|3.0.19 @d7d00036| |Candiate|trunk @abb0e177| | | | |Workload| | |Write size|4kb random| |Read size|4kb random| |Per Node Data|110GiB| |Generator|ndbench| |Key Distribution|Uniform| |SSTable Compr|Off| |Internode TLS|On (jdk)| |Internode Compr|On| |Compaction|LCS (320 MiB)| |Repair|Off| | | | |Hardware| | |Instance Type|i3.xlarge| |Deployment|96 us-east-1, 96 eu-west-1| |Region node count|96| | | | |OS Settings| | |IO scheduler|kyber| |Net qdisc|tc-fq| |readahead|32kb| |Java Version|OpenJDK 1.8.0_202 (Zulu)| | | | Second test is a [write scaling test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: was: Tracks evaluating a 192 node cluster with compression and encryption on. First test is a read scaling test [https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] |Test Setup| | |Baseline|3.0.19 @d7d00036| |Candiate|trunk @abb0e177| | | | |Workload| | |Write size|4kb random| |Read size|4kb random| |Per Node Data|110GiB| |Generator|ndbench| |Key Distribution|Uniform| |SSTable Compr|Off| |Internode TLS|On (jdk)| |Internode Compr|On| |Compaction|LCS (320 MiB)| |Repair|Off| | | | |Hardware| | |Instance Type|i3.xlarge| |Deployment|96 us-east-1, 96 eu-west-1| |Region node count|96| | | | |OS Settings| | |IO scheduler|kyber| |Net qdisc|tc-fq| |readahead|32kb| |Java Version|OpenJDK 1.8.0_202 (Zulu)| | | | Second test is a [write scaling test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > odd_netty_jdk_tls_cpu_usage.png, trunk_14400cRPS-14400cWPS.svg, > trunk_187000cRPS-14400cWPS.svg, trunk_187kcRPS_14kcWPS.png, > trunk_22000cRPS-14400cWPS-jdk.svg, trunk_22000cRPS-14400cWPS-openssl.svg, > trunk_220kcRPS_14kcWPS.png, trunk_252kcRPS-14kcWPS.png, > trunk_93500cRPS-14400cWPS.svg, trunk_LQ_14400cRPS-14400cWPS.svg, > trunk_LQ_21600cRPS-14400cWPS.svg, trunk_Q_21600cRPS-7200cWPS.svg, > trunk_allocation_Q_21k_cRPS.svg, trunk_vs_30x_125kcRPS_14kcWPS.png, > trunk_vs_30x_14kRPS_14kcWPS_load.png, trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > First test is a [read scaling test > |https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | > Second test is a [write scaling > test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cass
[jira] [Commented] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878164#comment-16878164 ] Joseph Lynch commented on CASSANDRA-15175: -- The QUORUM test is completed, results look pretty good on the read side: !trunk_vs_30x_Q_tcnative_summary.png! > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > odd_netty_jdk_tls_cpu_usage.png, trunk_14400cRPS-14400cWPS.svg, > trunk_187000cRPS-14400cWPS.svg, trunk_187kcRPS_14kcWPS.png, > trunk_22000cRPS-14400cWPS-jdk.svg, trunk_22000cRPS-14400cWPS-openssl.svg, > trunk_220kcRPS_14kcWPS.png, trunk_252kcRPS-14kcWPS.png, > trunk_93500cRPS-14400cWPS.svg, trunk_LQ_14400cRPS-14400cWPS.svg, > trunk_LQ_21600cRPS-14400cWPS.svg, trunk_Q_21600cRPS-7200cWPS.svg, > trunk_allocation_Q_21k_cRPS.svg, trunk_vs_30x_125kcRPS_14kcWPS.png, > trunk_vs_30x_14kRPS_14kcWPS_load.png, trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > Test setup at (reproduced below) > [https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | -- 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] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Attachment: trunk_vs_30x_Q_tcnative_summary.png > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > odd_netty_jdk_tls_cpu_usage.png, trunk_14400cRPS-14400cWPS.svg, > trunk_187000cRPS-14400cWPS.svg, trunk_187kcRPS_14kcWPS.png, > trunk_22000cRPS-14400cWPS-jdk.svg, trunk_22000cRPS-14400cWPS-openssl.svg, > trunk_220kcRPS_14kcWPS.png, trunk_252kcRPS-14kcWPS.png, > trunk_93500cRPS-14400cWPS.svg, trunk_LQ_14400cRPS-14400cWPS.svg, > trunk_LQ_21600cRPS-14400cWPS.svg, trunk_Q_21600cRPS-7200cWPS.svg, > trunk_allocation_Q_21k_cRPS.svg, trunk_vs_30x_125kcRPS_14kcWPS.png, > trunk_vs_30x_14kRPS_14kcWPS_load.png, trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > Test setup at (reproduced below) > [https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | -- 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] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Attachment: trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > odd_netty_jdk_tls_cpu_usage.png, trunk_14400cRPS-14400cWPS.svg, > trunk_187000cRPS-14400cWPS.svg, trunk_187kcRPS_14kcWPS.png, > trunk_22000cRPS-14400cWPS-jdk.svg, trunk_22000cRPS-14400cWPS-openssl.svg, > trunk_220kcRPS_14kcWPS.png, trunk_252kcRPS-14kcWPS.png, > trunk_93500cRPS-14400cWPS.svg, trunk_LQ_14400cRPS-14400cWPS.svg, > trunk_LQ_21600cRPS-14400cWPS.svg, trunk_Q_21600cRPS-7200cWPS.svg, > trunk_allocation_Q_21k_cRPS.svg, trunk_vs_30x_125kcRPS_14kcWPS.png, > trunk_vs_30x_14kRPS_14kcWPS_load.png, trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_summary.png, > trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > Test setup at (reproduced below) > [https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | -- 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] [Updated] (CASSANDRA-15198) Preventing RuntimeException when the username or password is empty
[ https://issues.apache.org/jira/browse/CASSANDRA-15198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-15198: Fix Version/s: 3.11.x 3.0.x 4.0 > Preventing RuntimeException when the username or password is empty > -- > > Key: CASSANDRA-15198 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15198 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 3.0.x, 3.11.x > > Attachments: CASSANDRA-15198-v1.patch, empty_username_error.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > !empty_username_error.jpg! > Although this does not affect the service, it's necessary to improve code > robustness. -- 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-15198) Preventing RuntimeException when the username or password is empty
[ https://issues.apache.org/jira/browse/CASSANDRA-15198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878143#comment-16878143 ] Blake Eggleston commented on CASSANDRA-15198: - |[3.0|https://github.com/bdeggleston/cassandra/tree/15198-3.0]|[circle|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15198-3.0]| |[3.11|https://github.com/bdeggleston/cassandra/tree/15198-3.11]|[circle|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15198-3.11]| |[trunk|https://github.com/bdeggleston/cassandra/tree/15198-trunk]|[circle|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/15198-trunk]| > Preventing RuntimeException when the username or password is empty > -- > > Key: CASSANDRA-15198 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15198 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Labels: pull-request-available > Attachments: CASSANDRA-15198-v1.patch, empty_username_error.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > !empty_username_error.jpg! > Although this does not affect the service, it's necessary to improve code > robustness. -- 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] [Updated] (CASSANDRA-15198) Preventing RuntimeException when the username or password is empty
[ https://issues.apache.org/jira/browse/CASSANDRA-15198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-15198: Reviewers: Blake Eggleston > Preventing RuntimeException when the username or password is empty > -- > > Key: CASSANDRA-15198 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15198 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Labels: pull-request-available > Attachments: CASSANDRA-15198-v1.patch, empty_username_error.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > !empty_username_error.jpg! > Although this does not affect the service, it's necessary to improve code > robustness. -- 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] [Updated] (CASSANDRA-15198) Preventing RuntimeException when the username or password is empty
[ https://issues.apache.org/jira/browse/CASSANDRA-15198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-15198: Impacts: Security (was: None) Test and Documentation Plan: unit testing new validation Status: Patch Available (was: Open) > Preventing RuntimeException when the username or password is empty > -- > > Key: CASSANDRA-15198 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15198 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Labels: pull-request-available > Attachments: CASSANDRA-15198-v1.patch, empty_username_error.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > !empty_username_error.jpg! > Although this does not affect the service, it's necessary to improve code > robustness. -- 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] [Updated] (CASSANDRA-15080) Paxos tables should use a 4KB chunk length
[ https://issues.apache.org/jira/browse/CASSANDRA-15080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15080: --- Summary: Paxos tables should use a 4KB chunk length (was: Paxos tables should use a 4KB chunk length (or no compression)) > Paxos tables should use a 4KB chunk length > -- > > Key: CASSANDRA-15080 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15080 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Jon Haddad >Priority: Normal > Labels: performance > Attachments: flamegraph-bad-perf.svg > > > In doing some research for a client on LWTs, I found that once we start > pushing a node hard enough, with enough LWTs, decompressing the data in the > paxos table takes up quite a bit of time. I've attached an SVG flame graph > showing about 10% of time is spent in LZ4_decompress_fast in queries hitting > the paxos table. We should be able to get a nice little performance bump > from changing this to 4KB chunk length or disabling it completely. -- 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] [Assigned] (CASSANDRA-15080) Paxos tables should use a 4KB chunk length
[ https://issues.apache.org/jira/browse/CASSANDRA-15080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad reassigned CASSANDRA-15080: -- Assignee: Jon Haddad > Paxos tables should use a 4KB chunk length > -- > > Key: CASSANDRA-15080 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15080 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Jon Haddad >Assignee: Jon Haddad >Priority: Normal > Labels: performance > Attachments: flamegraph-bad-perf.svg > > > In doing some research for a client on LWTs, I found that once we start > pushing a node hard enough, with enough LWTs, decompressing the data in the > paxos table takes up quite a bit of time. I've attached an SVG flame graph > showing about 10% of time is spent in LZ4_decompress_fast in queries hitting > the paxos table. We should be able to get a nice little performance bump > from changing this to 4KB chunk length or disabling it completely. -- 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-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878101#comment-16878101
]
Chris Lohfink commented on CASSANDRA-15194:
---
table naming changes sound good, I'll include them in patch. For now i think we
can stick with "mebibytes" and if theres ever a table thats not obvious what it
means that one can have special naming for it.
thinking {{live_rows_scanned}}?
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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] [Updated] (CASSANDRA-14670) Table Metrics Virtual Table
[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-14670:
-
Source Control Link:
[07ff9e57344f1d837e4aef3cbca26b953745bcd7|https://github.com/apache/cassandra/commit/07ff9e57344f1d837e4aef3cbca26b953745bcd7]
(was:
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-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878096#comment-16878096
]
Benedict commented on CASSANDRA-15194:
--
That works for tables that have a clear name, which might well be all of the
ones introduced that we're discussing. I'll try to find time to take a closer
look at all of the tables soon.
Whilst on that topic of table naming, I think some could be improved a little,
and I'd be interested to hear what you think. In particular, the latency
tables should IMO probably include {{latency}} in the name - both because it
isn't trivially obvious, and to not overly complicate future naming decisions
that cover the same category of things. {{live_scanned}} also probably has a
fairly unclear meaning to anybody not really well versed in C*.
What do you think?
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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=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-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878087#comment-16878087
]
Chris Lohfink commented on CASSANDRA-15194:
---
I actually like idea of just calling the column "mebibytes" since the table
names are things like "disk_usage" and "max_partition_size" its obvious what
its measuring and then the unit is unambiguous and no annoying capitalization
issues.
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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] [Comment Edited] (CASSANDRA-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878040#comment-16878040
]
Benedict edited comment on CASSANDRA-15194 at 7/3/19 6:00 PM:
--
> yet auto-uncapitalizes unquoted things
Wow, I did not know that. How awful. Perhaps we should separately at least
fix this for select queries so that, if a capitalised column exists, it selects
it. This seems strictly superior behaviour, though I guess you could have
weird schema where case determines the field. I'm sure we could have a safe
migration here, if we wanted, and it seems like a silly behaviour right now.
We could definitely safely fix this for system tables.
However, I'm not sure this is a huge problem here, since we're likely to mostly
be using "select *" I'd guess?
The problem is the other options are all even worse AFAICT, since {{mbs}} has
an ambiguous meaning, as a lowercase {{b}} can be interpreted either as bits or
bytes (and is I think non-standard for either). Though we have generally
interpreted it as bytes on this project, it's not great to continue the
ambiguity.
was (Author: benedict):
> yet auto-uncapitalizes unquoted things
Wow, I did not know that. How awful. Perhaps we should separately at least
fix this for select queries so that, if a capitalised column exists, it selects
it. This seems strictly superior behaviour, though I guess you could have
weird schema where case determines the field. I'm sure we could have a safe
migration here, if we wanted, and it seems like a silly behaviour right now.
However, I'm not sure this is a huge problem here, since we're likely to mostly
be using "select *" I'd guess?
The problem is the other options are all even worse AFAICT, since {{mbs}} has
an ambiguous meaning, as a lowercase {{b}} can be interpreted either as bits or
bytes (and is I think non-standard for either). Though we have generally
interpreted it as bytes on this project, it's not great to continue the
ambiguity.
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878040#comment-16878040
]
Benedict commented on CASSANDRA-15194:
--
> yet auto-uncapitalizes unquoted things
Wow, I did not know that. How awful. Perhaps we should separately at least
fix this for select queries so that, if a capitalised column exists, it selects
it. This seems strictly superior behaviour, though I guess you could have
weird schema where case determines the field. I'm sure we could have a safe
migration here, if we wanted, and it seems like a silly behaviour right now.
However, I'm not sure this is a huge problem here, since we're likely to mostly
be using "select *" I'd guess?
The problem is the other options are all even worse AFAICT, since {{mbs}} has
an ambiguous meaning, as a lowercase {{b}} can be interpreted either as bits or
bytes (and is I think non-standard for either). Though we have generally
interpreted it as bytes on this project, it's not great to continue the
ambiguity.
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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] [Comment Edited] (CASSANDRA-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878037#comment-16878037
]
Jon Haddad edited comment on CASSANDRA-15194 at 7/3/19 5:57 PM:
Or write megabytes / mebibytes, there's no ambiguity there.
was (Author: rustyrazorblade):
Or write "megabytes" to disambiguate.
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878037#comment-16878037
]
Jon Haddad commented on CASSANDRA-15194:
Or write "megabytes" to disambiguate.
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878013#comment-16878013
]
Chris Lohfink commented on CASSANDRA-15194:
---
My intent was to set rounding mode to UP so we never underreport so it would
stick at 0.001 for 2.2375e-16. If we just round down though yeah that would be
sufficient and wouldnt need a threshold.
capitalization in cql is kinda painful since its case sensitive yet
auto-uncapitalizes unquoted things. Also since everything else is in lower
snake case (likely because of that sensitivity) it _looks weird_. I do agree
that its ambiguous though, not sure best approach... could use mb and report in
1,000,000 of bytes or just stick with reporting bytes and punting
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877966#comment-16877966
]
Benedict commented on CASSANDRA-15194:
--
Sounds reasonable. Could you clarify what you mean by a rounding threshold,
though? A precision of 0.000 would seem to provide that by itself,
particularly if we just always truncate instead of round (i.e. set rounding
mode to always round down, which seems fine to me across the board)
I think we should probably properly capitalise MiB, though, since Mib has a
different meaning.
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877932#comment-16877932
]
Chris Lohfink commented on CASSANDRA-15194:
---
My thought here was to do:
* add units top the column names (max_ms, median_ms, disk_usage_mib)
* 0.000 precision
* have a rounding threshold, with our decaying algorithms they dont really go
to zero as nothing occurs within the alpha period. They just get exponentially
small. So if for latencies it goes below 1us and we displaying in ms with 0.000
precision we just display zero. And report space in MiB, with 0.000 precision,
but not zeroing out if below, just show as 0.001 since we dont want to
misrepresent in that direction.
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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] [Comment Edited] (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 edited comment on CASSANDRA-14670 at 7/3/19 3:10 PM:
bq. 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.
was (Author: rustyrazorblade):
> 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
[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] [Updated] (CASSANDRA-15198) Preventing RuntimeException when the username or password is empty
[ https://issues.apache.org/jira/browse/CASSANDRA-15198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zephyr Guo updated CASSANDRA-15198: --- Description: !empty_username_error.jpg! Although this does not affect the service, it's necessary to improve code robustness. was: !empty_username_error.jpg! Although this does not affect the service, but it's necessary to improve code robustness. > Preventing RuntimeException when the username or password is empty > -- > > Key: CASSANDRA-15198 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15198 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Labels: pull-request-available > Attachments: CASSANDRA-15198-v1.patch, empty_username_error.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > !empty_username_error.jpg! > Although this does not affect the service, it's necessary to improve code > robustness. -- 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] [Updated] (CASSANDRA-15198) Preventing RuntimeException when the username or password is empty
[ https://issues.apache.org/jira/browse/CASSANDRA-15198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-15198: --- Labels: pull-request-available (was: ) > Preventing RuntimeException when the username or password is empty > -- > > Key: CASSANDRA-15198 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15198 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Labels: pull-request-available > Attachments: CASSANDRA-15198-v1.patch, empty_username_error.jpg > > > !empty_username_error.jpg! > Although this does not affect the service, but it's necessary to improve code > robustness. -- 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] [Updated] (CASSANDRA-15198) Preventing RuntimeException when the username or password is empty
[ https://issues.apache.org/jira/browse/CASSANDRA-15198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zephyr Guo updated CASSANDRA-15198: --- Severity: Low Complexity: Low Hanging Fruit Discovered By: User Report Bug Category: Parent values: Security(12985)Level 1 values: Remote Code Execution(13002) Component/s: Feature/Authorization Status: Open (was: Triage Needed) > Preventing RuntimeException when the username or password is empty > -- > > Key: CASSANDRA-15198 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15198 > Project: Cassandra > Issue Type: Bug > Components: Feature/Authorization >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Attachments: CASSANDRA-15198-v1.patch, empty_username_error.jpg > > > !empty_username_error.jpg! > Although this does not affect the service, but it's necessary to improve code > robustness. -- 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] [Updated] (CASSANDRA-15198) Preventing RuntimeException when the username or password is empty
[ https://issues.apache.org/jira/browse/CASSANDRA-15198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zephyr Guo updated CASSANDRA-15198: --- Attachment: CASSANDRA-15198-v1.patch > Preventing RuntimeException when the username or password is empty > -- > > Key: CASSANDRA-15198 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15198 > Project: Cassandra > Issue Type: Bug >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Attachments: CASSANDRA-15198-v1.patch, empty_username_error.jpg > > > !empty_username_error.jpg! > Although this does not affect the service, but it's necessary to improve code > robustness. -- 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] [Created] (CASSANDRA-15198) Preventing RuntimeException when the username or password is empty
Zephyr Guo created CASSANDRA-15198: -- Summary: Preventing RuntimeException when the username or password is empty Key: CASSANDRA-15198 URL: https://issues.apache.org/jira/browse/CASSANDRA-15198 Project: Cassandra Issue Type: Bug Reporter: Zephyr Guo Assignee: Zephyr Guo Attachments: empty_username_error.jpg !empty_username_error.jpg! Although this does not affect the service, but it's necessary to improve code robustness. -- 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-15194) Improve readability of Table metrics Virtual tables units
[
https://issues.apache.org/jira/browse/CASSANDRA-15194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877654#comment-16877654
]
Benedict commented on CASSANDRA-15194:
--
We should probably standardise on number of digits after the decimal place in
any regard, and forbid scientific notation (though probably if we solve 0 it
would never get big enough to be a problem), to enhance readability
> Improve readability of Table metrics Virtual tables units
> -
>
> Key: CASSANDRA-15194
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15194
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Jon Haddad
>Assignee: Chris Lohfink
>Priority: Normal
>
> I just noticed this strange output in the coordinator_reads output::
> {code}
> cqlsh:system_views> select * from coordinator_reads ;
> count | keyspace_name | table_name | 99th | max |
> median | per_second
> ---+++--+-++
> 7573 | tlp_stress | keyvalue |0 | 0 |
>0 | 2.2375e-16
> 6076 | tlp_stress | random_access |0 | 0 |
>0 | 7.4126e-12
>390 | tlp_stress |sensor_data_udt |0 | 0 |
>0 | 1.7721e-64
> 30 | system | local |0 | 0 |
>0 | 0.006406
> 11 | system_schema |columns |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema |indexes |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | tables |0 | 0 |
>0 | 1.1192e-16
> 11 | system_schema | views |0 | 0 |
>0 | 1.1192e-16
> {code}
> cc [~cnlwsu]
> btw I realize the output is technically correct, but it's not very readable.
> For practical purposes this should just say 0.
--
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
