[
https://issues.apache.org/jira/browse/HBASE-15160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030526#comment-16030526
]
Yu Li commented on HBASE-15160:
-------------------------------
bq. why do you think that updating the metrics should be pulled up the stack?
Since there's a synchronization in {{getMetaBlock}} and up the stack we could
record the IO time of {{getMetaBlock}} outside the lock. But considering in
real world meta is cached for most case, it's ok to exclude the IO time of it.
So this is not an argument but just a clarification of my thought since you
asked (smile).
I think reasons like making it easier for backport stands, so current patch
LGTM. Let me check YCSB to make sure no performance regression with it (should
be since the current patch is quite similar to the one we're running online).
> Put back HFile's HDFS op latency sampling code and add metrics for monitoring
> -----------------------------------------------------------------------------
>
> Key: HBASE-15160
> URL: https://issues.apache.org/jira/browse/HBASE-15160
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 2.0.0, 1.1.2
> Reporter: Yu Li
> Assignee: Yu Li
> Priority: Critical
> Attachments: HBASE-15160.patch, HBASE-15160_v2.patch,
> HBASE-15160_v3.patch, hbase-15160_v4.patch, hbase-15160_v5.patch,
> hbase-15160_v6.patch
>
>
> In HBASE-11586 all HDFS op latency sampling code, including fsReadLatency,
> fsPreadLatency and fsWriteLatency, have been removed. There was some
> discussion about putting them back in a new JIRA but never happened.
> According to our experience, these metrics are useful to judge whether issue
> lies on HDFS when slow request occurs, so we propose to put them back in this
> JIRA, and add the metrics for monitoring as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
