You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Caleb Rackliffe (Jira)" <ji...@apache.org> on 2021/07/06 19:52:00 UTC
[jira] [Comment Edited] (CASSANDRA-16760) JMXTimer exposes
attributes in inconsistent time units
[ https://issues.apache.org/jira/browse/CASSANDRA-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375976#comment-17375976 ]
Caleb Rackliffe edited comment on CASSANDRA-16760 at 7/6/21, 7:51 PM:
----------------------------------------------------------------------
[~yifanc] Made one minor comment on the dtest PR, but outside of that and a couple [linter items|https://app.travis-ci.com/github/apache/cassandra-dtest/builds/231838725], everything LGTM
was (Author: maedhroz):
[~yifanc] Made one minor comment on the dtest PR, but otherwise, everything LGTM
> JMXTimer exposes attributes in inconsistent time units
> ------------------------------------------------------
>
> Key: CASSANDRA-16760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16760
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
> Reporter: Yifan Cai
> Assignee: Yifan Cai
> Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> JMXTimer objects are constructed with a duration time unit, which is fixed to MICROSECONDS in the codebase. According to that, we should expect the time values returned from the JXMTimer are in micros.
> However, the time unit is inconsistent among the JMXTimer attributes.
> Most of the attributes such as percentiles and mean values returned are in micros, except Values and RecentValues.
> Those 2 attributes expose the raw histogram values of the underlying Timer (CodaHale) and the values are fixed to be based on nanos.
> The inconsistency leads to confusion and mis-interpretation of the values, if the end user is not familiar with the implementation details. One may consider the Values and RecentValues are also in micros.
> Besides the confusion, given the intention is to record the time values in the micros resolution, we do not need to allocate 165 buckets in the DecayingEstimatedHistogramReservoir. 165 buckets is necessary for nanos, but not for micros. We can only allocate 90 buckets and it should reduce ~50% memory footprint used by the Timers.
> I'd like to propose an approach to scale the values being recorded in the reservoirs used by Timers and reduce the allocation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org