[ https://issues.apache.org/jira/browse/OAK-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362338#comment-16362338 ]
Andrei Dulceanu commented on OAK-7262: -------------------------------------- [~frm], looking at possible {{Reservoir}} implementations needed for backing up the {{Histogram}} used for bookkeeping the commit time, I came across of {{UniformReservoir}}, which provides a random sampling reservoir, "which offers a 99.9% confidence level with a 5% margin of error assuming a normal distribution" (according to the JavaDoc). I think this is a reasonable choice, since it uses under the hood an {{AtomicLongArray}} (no locks acquired for important operations such as #size, #getSnapshot, etc.). My idea is to replace the implementation and start measuring the effect by running some of our benchmarks (patched vs trunk) to asses whether there's a performance gain or not. WDYT? > LockBasedScheduler#getHeadNodeState poor performance due to lock contention > in commitTimeHistogram implementation > ----------------------------------------------------------------------------------------------------------------- > > Key: OAK-7262 > URL: https://issues.apache.org/jira/browse/OAK-7262 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar > Reporter: Andrei Dulceanu > Assignee: Andrei Dulceanu > Priority: Major > Fix For: 1.9.0, 1.10 > > > With OAK-4732, we slightly prioritised reads, allowing callers of > {{LockBasedScheduler#getHeadNodeState}} to wait for a certain amount of time > on the commit semaphore, in order to fetch the latest head. The amount of > time to wait for was computed as the median of the latest 1000 commits, but > the implementation was flexible enough to replace the 0.5 quantile with a > different value. > The initial implementation used {{SynchronizedDescriptiveStatistics}} from > {{commons-math3}}. In OAK-6430, we replaced that with a {{Histogram}} backed > by a {{SlindingWindowReservoir}} from the dropwizard metric library > ({{io.dropwizard.metrics}}). > One of the problems observed with the current implementation is that, under > heavy loading, the performance of {{LockBasedScheduler#getHeadNodeState}} > decreases due to lock contention in {{commitTimeHistogram}} implementation. > Namely, {{SlidingWindowReservoir#getSnapshot}} seems to be a bottleneck. It > copies an array of 1000 elements at each invocation of > {{LockBasedScheduler#getHeadNodeState}}, acquiring and releasing a lock for > each element in the array. -- This message was sent by Atlassian JIRA (v7.6.3#76005)