[
https://issues.apache.org/jira/browse/HBASE-13420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484519#comment-14484519
]
John Leach commented on HBASE-13420:
------------------------------------
I think this metric is way to broad to be coherent. Is it the latency on a
postRegionOperation call or a prePut on the observer?
The definition of the metric would be: The first N (100) latencies from any
possible coprocessor call for a specific Region Observer refreshed every 45
seconds. Still working on a clever Acronym...
Would it make sense to build an actual bean for each of the observers that
actually reports real metrics and is registered in jmx following the signature
of the observer?
We clearly need a short term fix, but I am concerned we are continuing a metric
that really serves no purpose.
What purpose does this metric serve?
> RegionEnvironment.offerExecutionLatency Blocks Threads under Heavy Load
> -----------------------------------------------------------------------
>
> Key: HBASE-13420
> URL: https://issues.apache.org/jira/browse/HBASE-13420
> Project: HBase
> Issue Type: Improvement
> Reporter: John Leach
> Assignee: Andrew Purtell
> Attachments: HBASE-13420.patch, HBASE-13420.txt,
> offerExecutionLatency.tiff
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> The ArrayBlockingQueue blocks threads for 20s during a performance run
> focusing on creating numerous small scans.
> I see a buffer size of (100)
> private final BlockingQueue<Long> coprocessorTimeNanos = new
> ArrayBlockingQueue<Long>(
> LATENCY_BUFFER_SIZE);
> and then I see a drain coming from
> MetricsRegionWrapperImpl with 45 second executor
> HRegionMetricsWrapperRunable
> RegionCoprocessorHost#getCoprocessorExecutionStatistics()
> RegionCoprocessorHost#getExecutionLatenciesNanos()
> Am I missing something?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
