[
https://issues.apache.org/jira/browse/CASSANDRA-11752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355290#comment-15355290
]
Per Otterström edited comment on CASSANDRA-11752 at 6/29/16 2:25 PM:
---------------------------------------------------------------------
Attached fix for CASSANDRA-11752
I ended up implementing a completely new histogram reservoir as it seemed to be
the most clean approach.
The new DecayingEstimatedHistogramReservoir class holds two different sets of
buckets, one with decay and one without. The buckets without decay will only be
exposed on call to getValues(), other methods in a snapshot will expose values
based on the decaying buckets. This way we're compatible with clients pulling
raw bucket values, while still serving reasonable values on the percentiles
which are biased towards the most recent minutes.
The snapshot will not create a copy of the non-decaying buckets up front in
order to not allocate and free memory without using it. Internal calls as well
as most clients will probably not use the raw values any way.
was (Author: eperott):
Fix for CASSANDRA-11752
> histograms/metrics in 2.2 do not appear recency biased
> ------------------------------------------------------
>
> Key: CASSANDRA-11752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11752
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Chris Burroughs
> Assignee: Per Otterström
> Labels: metrics
> Attachments: 11752-2.2.txt, boost-metrics.png,
> c-jconsole-comparison.png, c-metrics.png, default-histogram.png
>
>
> In addition to upgrading to metrics3, CASSANDRA-5657 switched to using a
> custom histogram implementation. After upgrading to Cassandra 2.2
> histograms/timer metrics are not suspiciously flat. To be useful for
> graphing and alerting metrics need to be biased towards recent events.
> I have attached images that I think illustrate this.
> * The first two are a comparison between latency observed by a C* 2.2 (us)
> cluster shoring very flat lines and a client (using metrics 2.2.0, ms)
> showing server performance problems. We can't rule out with total certainty
> that something else isn't the cause (that's why we measure from both the
> client & server) but they very rarely disagree.
> * The 3rd image compares jconsole viewing of metrics on a 2.2 and 2.1
> cluster over several minutes. Not a single digit changed on the 2.2 cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
