[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735418#comment-17735418
]
Stefan Miklosovic edited comment on CASSANDRA-18305 at 6/20/23 6:52 PM:
------------------------------------------------------------------------
There are three approaches in general
1) we fix ccm, this would be needed (1)
The advantage of 1) is that we do not need to change anything in dtests at all
and it will be all backward compatible and we do not break anything for anybody
and we can change the output in nodetool in trunk.
Disadvantage is that we need to do this in ccm, I am not sure how this works in
regards of dtests / ccm we are using there, some images need to be released
with the patch, no?
2) we do not fix it in ccm, that means we need to fix it in dtests like this (2)
The downside of that is that we break ccm because ccm will not be aligned with
the work in trunk anymore.
The third option is to completely bypass this by not reading the output but
reading a metric from JMX. That solution would be on par when it comes to ccm
changes / releases so it is basically same as 1) but the advantage is that we
are not dependent on some nodetool ouput (!!!) anymore. As I mentioned above,
that metric is there from 2.1 beta1.
Thanks for looking into it in advance! Really appreciate it.
(1) https://github.com/riptano/ccm/pull/752/files
(2) https://github.com/smiklosovic/cassandra-dtest/tree/CASSANDRA-18305
was (Author: smiklosovic):
There are two approaches in general
1) we fix ccm, this would be needed (1)
The advantage of 1) is that we do not need to change anything in dtests at all
and it will be all backward compatible and we do not break anything for anybody
and we can change the output in nodetool in trunk.
Disadvantage is that we need to do this in ccm, I am not sure how this works in
regards of dtests / ccm we are using there, some images need to be released
with the patch, no?
2) we do not fix it in ccm, that means we need to fix it in dtests like this (2)
The downside of that is that we break ccm because ccm will not be aligned with
the work in trunk anymore.
The third option is to completely bypass this by not reading the output but
reading a metric from JMX. That solution would be on par when it comes to ccm
changes / releases so it is basically same as 1) but the advantage is that we
are not dependent on some nodetool ouput (!!!) anymore. As I mentioned above,
that metric is there from 2.1 beta1.
Thanks for looking into it in advance! Really appreciate it.
(1) https://github.com/riptano/ccm/pull/752/files
(2) https://github.com/smiklosovic/cassandra-dtest/tree/CASSANDRA-18305
> Enhance nodetool compactionstats with existing MBean metrics
> ------------------------------------------------------------
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
> Reporter: Brad Schoening
> Assignee: Manish Ghildiyal
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
