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

Elliott Clark commented on HBASE-8370:
--------------------------------------

bq.I disagree that its not actionable. I would go fix the block cache in this 
case. 
My opinion would be that metrics should be useful for they Guys and Girls on 
the ops teams.  If the metrics published aren't usable by them then most users 
are paying a cost for things that only interest us devs.  Tracing, trace level 
logging and debuggers should provide enough info to diagnose most of the block 
cache features you are talking about.

The path, of adding metrics for devs, is what first got us SchemaMetrics. Some 
devs were investigating how and when to use multi level indexes in HFileV2.  
Everyone paid the cost for those metrics even after the issues had all be 
solved.  I'm really just trying to make sure we don't repeat the same mistakes.

bq.I would agree that index block metrics are not needed or actionable if it is 
indeed the case that we pin index blocks forever.
They are always the last to be evicted yes. 
https://github.com/apache/hbase/blob/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CachedBlock.java#L125


                
> 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 [email protected]
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to