jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomek Rękawek (JIRA) <j...@apache.org>
Subject [jira] [Commented] (OAK-4882) Bottleneck in the asynchronous persistent cache
Date Mon, 31 Oct 2016 10:30:58 GMT

    [ https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621825#comment-15621825
] 

Tomek Rękawek commented on OAK-4882:
------------------------------------

Implemented a simple benchmark in OAK-5035. The way to reproduce [original issue|OAK-2761]:

{noformat}
$ java -DcacheOptions="size=100,+compact,-async" -jar target/oak-run-1.6-SNAPSHOT.jar benchmark
--concurrency=8 PersistentCacheTest Oak-Mongo
Apache Jackrabbit Oak 1.6-SNAPSHOT
# PersistentCacheTest              C     min     10%     50%     90%     max       N
Oak-Mongo                          8     122     215     278     353    3403    1520
{noformat}

The max = 3403 indicates that at some point during the test the threads are locked on the
compaction process during generation switch (it can be confirmed with a debugger). On the
other hand, after enabling +async mode the results are as follows:

{noformat}
java -DcacheOptions="size=100,+compact,+async" -jar target/oak-run-1.6-SNAPSHOT.jar benchmark
--concurrency=8 PersistentCacheTest Oak-Mongo
Apache Jackrabbit Oak 1.6-SNAPSHOT
# PersistentCacheTest              C     min     10%     50%     90%     max       N
Oak-Mongo                          8      55      73      91     124     356    4998
{noformat}

So, it seems that there's no more hangup there.

I'll also try to measure how many put() entries are discarded (by the heuristics and the full
queue).

> Bottleneck in the asynchronous persistent cache
> -----------------------------------------------
>
>                 Key: OAK-4882
>                 URL: https://issues.apache.org/jira/browse/OAK-4882
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: cache, documentmk
>    Affects Versions: 1.5.10, 1.4.8
>            Reporter: Tomek Rękawek
>            Assignee: Tomek Rękawek
>             Fix For: 1.6, 1.5.13
>
>         Attachments: OAK-4882.patch
>
>
> The class responsible for accepting new cache operations which will be handled asynchronously
is [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java].
In case of a high load, when the queue is full (=1024 entries), the [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86]
method removes the oldest 256 entries. However, we can't afford losing the updates (as it
may result in having stale entries in the cache), so all the removed entries are compacted
into one big invalidate action.
> The compaction action ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97])
still holds the lock taken in add() method, so threads which tries to add something to the
queue have to wait until cleanTheQueue() ends.
> Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so it won't
hold the lock for the whole time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message