cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Yeksigian (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
Date Tue, 17 Nov 2015 16:18:11 GMT


Carl Yeksigian commented on CASSANDRA-10585:

While the version for 2.1 is fine, for 2.2 and 3.0, I don't think we should switch to {{ExponentiallyDecayingReservoir}};
the reasoning behind us using {{EstimatedHistogram}} is discussed in CASSANDRA-5657.

I'd like to either come up with a way to either estimate the statistic trying to be calculated
here, or extend {{EstimatedHistogram}} to properly capture a 0 value. I think we can approximate
this by using the {{RowCacheHit}}/{{RowCacheMiss}} metrics; that would mean {{SSTablesPerReadHistogram}}
is only captured on {{RowCacheMiss}}, so the new metric might be
(RowCacheMiss/(RowCacheHit + RowCacheMiss)) * SSTablesPerRead

Do either of those seem feasible, [~isburmistrov]?

> SSTablesPerReadHistogram seems wrong when row cache hit happend
> ---------------------------------------------------------------
>                 Key: CASSANDRA-10585
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Ivan Burmistrov
>            Priority: Minor
>             Fix For: 2.1.x, 2.2.x, 3.0.x
>         Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, SSTablePerReadHistogram_RowCache-cassandra-2_2.patch,
> SSTablePerReadHistogram metric now not considers case when row has been read from row
> And so, this metric will have big values even almost all requests processed by row cache
(and without touching SSTables, of course).
> So, it seems that correct behavior is to consider that if we read row from row cache
then we read zero SSTables by this request.
> The patch at the attachment.

This message was sent by Atlassian JIRA

View raw message