Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 3 Apr 2012 16:34:24 +0000 (UTC)
From: "stack (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1971096699.6940.1333470864318.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <221056109.33006.1332191259657.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-5601) Add per-column-family data block
 cache hit ratios
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

stack commented on HBASE-5601:
------------------------------

bq. Make Per-cf and global block cache metrics naming consistent (hbase.regionserver.blockCacheHitCount vs hbase.RegionServerDynamicStatistics.tbl.usertable.cf.ycsb.bt.Data.fsBlockReadCacheHitCnt)

Is it really named the latter?  Please fix (Proposal looks good).

bq. Rename hbase.RegionServerDynamicStatistics.XXX -> hbase.regionserver.dyn.XXX

hbase-5701 just committed did this (sort-of).

bq. Rename dynamic metric names tbl.usertable.cf.ycsb.bt.Data.fsBlockReadCacheHitCnt -> tbl=usertable.cf=ycsb.bt=Data.at=scan.BlockCacheHitCount. Here at stands for access type, and can be scan or compaction.

I don't follow the above.  Something didn't make it across.

bq. For at=compaction, we probably do not need per-block type (Data, Index, ...) metric values, shall we aggregate them?

Sure, on compaction.

bq. Shall we extend per-cf metrics into HBASE-5533 (read/write latency histograms)?

That would be sweet but maybe for later.

bq. With slab cache, we may no longer have one global block cache. Shall we enable per-cache type metrics? This can imply renaming hbase.regionserver.blockCache => hbase.regionserver.lrublockcache, slabblockcache, etc.

Having them distinctly named makes sense to me.

bq. Add a configuration for disabling per-cf metrics.

Yes.  There could be an overwhelming amount.

ba. Thoughts?

Sounds excellent.  Sounds like work that would be checked in with the singularity, 0.96?
                
> Add per-column-family data block cache hit ratios
> -------------------------------------------------
>
>                 Key: HBASE-5601
>                 URL: https://issues.apache.org/jira/browse/HBASE-5601
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Mikhail Bautin
>            Assignee: Enis Soztutar
>
> In addition to the overall block cache hit ratio it would be extremely useful to have per-column-family data block cache hit ratio metrics.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira