[
https://issues.apache.org/jira/browse/HBASE-13420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-13420:
-----------------------------------
Attachment: hbase-13420.tar.gz
So what do we think about this? Leave as is or try the
BoundedConcurrentLinkedQueue alternative? According to my experiments it will
have better behavior under actual conditions, but ConcurrentLinkedQueue does
have what looks like an interesting worst case under high concurrency. I've
attached the JMH harness used for the test if you'd like to reproduce. Maybe
your findings are different? If so that would be interesting. (I used an EC2
c3.4xlarge for running the test, FWIW)
I could also look for a better concurrent structure or roll my own for this use
case (bounded sample reservoir at high concurrency). That might be
overengineering the problem here though.
> 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, hbase-13420.tar.gz,
> 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)
