hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-8370) Report data block cache hit rates apart from aggregate cache hit rates
Date Wed, 21 May 2014 22:12:41 GMT

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

stack commented on HBASE-8370:
------------------------------

In trunk we do not have per block type metrics.

In trunk we do not show the cache hit rates in the UI apart from what can be found in the
metrics listing under /jmx

So I could close this issue I suppose because the pivot around which the above discussion
turns no longer exists in trunk.

But the discussion above is good around making it more plain when problematic evictions are
happening in your online serving system.

I could file an issue to make it so the block cache percentage is a double rather than an
int -- the one thing the two lads agreed to above -- but I can't help but think that most
operators will not be concerned if their block cache hit ratio goes from 99.45% to 99.41%
([~varunsharma]'s point, in synopsis, is that significant changes in blockcache loading should
be more obvious; [~andrew.purtell@gmail.com] agrees).

Let me just do this anyways.  I just made a sub-jira

So, I want to add back blocktype reporting to trunk -- data blocks at least (I went looking
for such reporting because I've been messing with block cache and have been wanting to know
what is going on inside, a recurring theme if you search JIRA) -- but while our [~eclark]
starts out at an extreme (conflating block type reporting with the heavyweight per-columnfamily/table/region
SchemaMetrics system since purged), his argument that we should only expose "actionable" metrics
has merit. For example, in my case, excepting DoubleBlockCache (slabcache), caches are tiered
with meta (index/blooms) in the LRCBC and the everything else in the L2; in this case reporting
on data block metrics is redundant (On other hand, most run with just one BC implementation...)

While we could probably resolve, let me leave this issue open.  We still need a 'fix'.  I'll
be back.




> Report data block cache hit rates apart from aggregate cache hit rates
> ----------------------------------------------------------------------
>
>                 Key: HBASE-8370
>                 URL: https://issues.apache.org/jira/browse/HBASE-8370
>             Project: HBase
>          Issue Type: Improvement
>          Components: metrics
>            Reporter: Varun Sharma
>            Assignee: Varun Sharma
>            Priority: Minor
>
> Attaching from mail to dev@hbase.apache.org
> I am wondering whether the HBase cachingHitRatio metrics that the region server UI shows,
can get me a break down by data blocks. I always see this number to be very high and that
could be exagerated by the fact that each lookup hits the index blocks and bloom filter blocks
in the block cache before retrieving the data block. This could be artificially bloating up
the cache hit ratio.
> Assuming the above is correct, do we already have a cache hit ratio for data blocks alone
which is more obscure ? If not, my sense is that it would be pretty valuable to add one.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message