cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Lohfink (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-7731) Get max values for live/tombstone cells per slice
Date Mon, 15 Sep 2014 16:19:34 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134064#comment-14134064
] 

Chris Lohfink edited comment on CASSANDRA-7731 at 9/15/14 4:18 PM:
-------------------------------------------------------------------

bq. we don't want to change it to be the maximum value since the application started

maximum value since the application started is the only option.  The only thing the reservoir
is used for is for the percentiles like 50th, 75th, 90th etc.  Only thing you can change in
theory is to use a uniform reservoir instead of a decaying reservoir to be the same (since
start of app instead of last 5 min).  The min,max,count,sum,std dev etc are all based on since
C* started. 

In the newer versions of Metrics all the values would be computed from the reservoir snapshot
so it would follow the 5 min-ish result.  




was (Author: cnlwsu):
bq. we don't want to change it to be the maximum value since the application started

maximum value since the application started is the only option.  The only thing the reservoir
is used for is for the percentiles like 50th, 75th, 90th etc.  Only thing you can change in
theory is to use a uniform reservoir instead of a EWMA reservoir to be the same (since start
of app instead of last 5 min).  The min,max,count,sum,std dev etc are all based on since C*
started. 

In the newer versions of Metrics all the values would be computed from the reservoir snapshot
so it would follow the 5 min-ish result.  



> Get max values for live/tombstone cells per slice
> -------------------------------------------------
>
>                 Key: CASSANDRA-7731
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7731
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Cyril Scetbon
>            Assignee: Robert Stupp
>            Priority: Minor
>             Fix For: 2.1.1
>
>         Attachments: 7731-2.0.txt, 7731-2.1.txt
>
>
> I think you should not say that slice statistics are valid for the [last five minutes
|https://github.com/apache/cassandra/blob/cassandra-2.0/src/java/org/apache/cassandra/tools/NodeCmd.java#L955-L956]
in CFSTATS command of nodetool. I've read the documentation from yammer for Histograms and
there is no way to force values to expire after x minutes except by [clearing|http://grepcode.com/file/repo1.maven.org/maven2/com.yammer.metrics/metrics-core/2.1.2/com/yammer/metrics/core/Histogram.java#96]
it . The only thing I can see is that the last snapshot used to provide the median (or whatever
you'd used instead) value is based on 1028 values.
> I think we should also be able to detect that some requests are accessing a lot of live/tombstone
cells per query and that's not possible for now without activating DEBUG for SliceQueryFilter
for example and by tweaking the threshold. Currently as nodetool cfstats returns the median
if a low part of the queries are scanning a lot of live/tombstone cells we miss it !



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message