Alex Parvulescu created OAK-3168:
------------------------------------
Summary: SegmentCache flushes Segment on update
Key: OAK-3168
URL: https://issues.apache.org/jira/browse/OAK-3168
Project: Jackrabbit Oak
Issue Type: Bug
Components: segmentmk
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
The SegmentCache currently uses the cache eviction call to remove the Segment
instance from memory to help keep the cache memory requirements under control
[0].
What I've noticed though, is that for a cache update (existing key) there will
also be an eviction call happening, which results in a lot of extra IO pressure
on the SegmentStore which not only is not able to cache the segment, but is
forced to reload it multiple times as the reference gets nullified after each
load.
This comes from the sampling behavior of the SegmentId: it will not hit the
cache each time it needs to load a new Segment, but rather load it from IO and
(re)place it in the cache, based on a sampling rate [1].
Now I see 2 options:
* change the cache code to _not_ call the eviction callback on updates (or
allow disabling this call on updates)
* change the SegmentTracker code to add the value to the cache only if it's
not there as Segments are immutable, so no harm done.
Raised this issue offline with [~tmueller], [~mduerig] first and as I
understand [~mduerig] is in favor of option one, while [~tmueller] proposed
that the Lirs cache impl should be inline with what the guava cache does, and
depending on that we could choose the right fix here.
Hope this covers everything.
[0]
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentTracker.java#L133
[1]
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentId.java#L135
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
