You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2015/10/13 16:22:05 UTC
[jira] [Resolved] (OAK-3330) FileStore lock contention with
concurrent writers
[ https://issues.apache.org/jira/browse/OAK-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dürig resolved OAK-3330.
--------------------------------
Resolution: Fixed
* {{Segment.readString()}} loads the segment even when the string is in the string cache. Fixed at http://svn.apache.org/viewvc?rev=1708401&view=rev
* Use read/write lock in {{FileStore}} instead of synchronize: http://svn.apache.org/viewvc?rev=1708402&view=rev
* Read from {{FileChannel}} instead of {{RandomAccessFile}} to reduce concurrency: http://svn.apache.org/viewvc?rev=1708403&view=rev
With above changes I see an increase of just above 50% in write throughput with {{SegmenCompactionIT}} and above parameters.
> FileStore lock contention with concurrent writers
> -------------------------------------------------
>
> Key: OAK-3330
> URL: https://issues.apache.org/jira/browse/OAK-3330
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Labels: compaction
> Fix For: 1.4
>
> Attachments: OAK-3330.patch
>
>
> Concurrently writing to the file store can lead to a sever lock contention in {{FileStore#readSegment}}. That method searches the current {{TarWriter}} instance for the segment once it could not be found in any of the {{TarReader}} instances. This is the point where synchronizes on the {{FileStore}} instance, which leads to the contention.
> The effect is only observable once the segment cache becomes full and reads actually need to go to the file store. Thus a possible improvement could be to pin segments from the current tar writer to the cache. Alternatively we could try to ease locking by employing read/write locks where possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)