Major Description
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