[
https://issues.apache.org/jira/browse/CASSANDRA-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786655#comment-17786655
]
Stefan Miklosovic edited comment on CASSANDRA-19015 at 11/16/23 8:27 AM:
-------------------------------------------------------------------------
This is all good effort, good ticket to work on. However, what I would do for
latencies is that I would not dynamically change the unit of value - once ms,
once us. No, I would do just all "ms" to be consistent with it. It is something
different with sizes (GB, MB ...) that could stay, but when I have one latency
as 500 ms and then another 567 us, the brain thinks that all of this is ms but
it has to additionally parse "aha this is in micro". It was all in "ms" before
as well. Just fix the decimal points, for "ratios" too.
Also, if it is once in ms and once in us, what if somebody writes a script
which parses the values and they plot it somewhere or similar? Then they would
have additional work in converting microseconds to milliseconds. If it is all
milliseconds they have less job to do.
Actually, for sizes, non-human readable output should write just raw numbers.
Human readable output should convert it to gb/mb/kb ... That is currently
inconsistent as well.
was (Author: smiklosovic):
This is all good effort, good ticket to work on. However, what I would do for
latencies is that I would not dynamically change the unit of value - once ms,
once us. No, I would do just all "ms" to be consistent with it. It is something
different with sizes (GB, MB ...) that could stay, but when I have one latency
as 500 ms and then another 567 us, the brain thinks that all of this is ms but
it has to additionally parse "aha this is in micro". It was all in "ms" before
as well. Just fix the decimal points, for "ratios" too.
Also, if it is once in ms and once in us, what if somebody writes a script
which parses the values and they plot it somewhere or similar? Then they would
have additional work in converting microseconds to milliseconds. If it is all
milliseconds they have less job to do.
> Nodetool 'tablestats' formatting uses inconsistent significant digits
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-19015
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19015
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
> Reporter: Brad Schoening
> Assignee: Leo
> Priority: Low
> Attachments: CASSANDRA-19015.txt
>
>
> Nodetool reports milliseconds (ms) with anywhere from 3 to 15 significant
> digits. Ratios use five or sixteen decimal places. Averages use 1 or 13
> decimal places.
> * milliseconds should use 3 decimal places
> * ratios should use 3 decimal places (tenths of a percent)
> * averages should use 1 or 2
> For readability, it would be helpful if large integers had comma separators.
> I.e., space used: as 1,463,210,998,523 and/or in GiB/MiB/KiB. It's unclear
> if the exact disk size is somehow useful, as it may change minute-by-minute,
> if not, rounding would be best, or displaying both Space used (live):
> 1,463,210,998,523 (1,463GiB)
> Total number of tables: 83
> ----------------
> Keyspace : X
> Read Count: 1007337271
> Read Latency: 8.485891803649942 ms
> Write Count: 67550181
> Write Latency: 0.02556443163342523 ms
> Pending Flushes: 0
> Table: Y
> SSTable count: 7183
> Old SSTable count: 0
> SSTables in each level: [0, 9, 92, 754, 6328, 0, 0, 0, 0]
> Space used (live): 1463210998523
> Space used (total): 1463210998523
> Space used by snapshots (total): 0
> Off heap memory used (total): 607419608
> SSTable Compression Ratio: 0.3146620992793412
> Number of partitions (estimate): 24784137
> Memtable cell count: 106067
> Memtable data size: 248539982
> Memtable off heap memory used: 0
> Memtable switch count: 256
> Local read count: 865440924
> Local read latency: 6.857 ms
> Local write count: 13881409
> Local write latency: 0.037 ms
> Pending flushes: 0
> Percent repaired: 0.0
> Bytes repaired: 0.000KiB
> Bytes unrepaired: 4315.386GiB
> Bytes pending repair: 0.000KiB
> Bloom filter false positives: 11027855
> Bloom filter false ratio: 0.01099
> Bloom filter space used: 33590024
> Bloom filter off heap memory used: 33532560
> Index summary off heap memory used: 8174024
> Compression metadata off heap memory used: 565713024
> Compacted partition minimum bytes: 36
> Compacted partition maximum bytes: 17797419593
> Compacted partition mean bytes: 189740
> Average live cells per slice (last five minutes): 1443.2146104466253
> Maximum live cells per slice (last five minutes): 105778
> Average tombstones per slice (last five minutes): 1.0
> Maximum tombstones per slice (last five minutes): 1
> Dropped Mutations: 0
> Droppable tombstone ratio: 0.00000
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
