[
https://issues.apache.org/jira/browse/HBASE-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927243#action_12927243
]
Gary Helmling commented on HBASE-1956:
--------------------------------------
Correction #2: both HFile and HLog reset the static counter variables in the
corresponding get* methods. As I mentioned above the "fsSyncLatency" metric
was not being reset at the end of the metrics context period. So the
fsSyncLatency min/max values would have been carrying through regardless. But
if the other metrics (fsReadLatency, fsWriteLatency) were showing increasing
counts, that would indicate a race in re-assigning the metric counters.
> Export HDFS read and write latency as a metric
> ----------------------------------------------
>
> Key: HBASE-1956
> URL: https://issues.apache.org/jira/browse/HBASE-1956
> Project: HBase
> Issue Type: Improvement
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Priority: Minor
> Fix For: 0.90.0
>
> Attachments: HBASE-1956.patch, HBASE-1956.patch
>
>
> HDFS write latency spikes especially are an indicator of general cluster
> overloading. We see this where the WAL writer complains about writes taking >
> 1 second, sometimes > 4, etc. If for example the average write latency over
> the monitoring period is exported as a metric, then this can feed into
> alerting for or automatic provisioning of additional cluster hardware. While
> we're at it, export read side metrics as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
