[
https://issues.apache.org/jira/browse/OAK-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575479#comment-15575479
]
Thomas Mueller commented on OAK-4936:
-------------------------------------
I can reproduce the problem. I think it is related to the (relatively) special
use case, but it should be possible to solve the problem. What is a bit special
is that entries sizes are relatively big, so that there are relatively few
entries in the cache (around 400). I could improve the performance a lot using
the attached patch: when loading non-resident entries (where the key is in the
cache, but the value was evicted), currently entries stay cold. If they become
hot in this case, performance is greatly improved. I need to check the LIRS
specification for this case, to ensure this doesn't hurt other use cases. I
also decreased the segment count and stack move distance, but not sure if
that's important.
{noformat}
--- src/main/java/org/apache/jackrabbit/oak/cache/CacheLIRS.java
(revision 1764860)
+++ src/main/java/org/apache/jackrabbit/oak/cache/CacheLIRS.java
(working copy)
@@ -78,6 +78,11 @@
static final Logger LOG = LoggerFactory.getLogger(CacheLIRS.class);
static final ThreadLocal<Integer> CURRENTLY_LOADING = new
ThreadLocal<Integer>();
private static final AtomicInteger NEXT_CACHE_ID = new AtomicInteger();
+ private static final boolean PUT_HOT =
Boolean.parseBoolean(System.getProperty("oak.cacheLIRS.putHot", "true"));
+
+ static {
+ LOG.info("CacheLIRS putHot=" + PUT_HOT);
+ }
/**
* Listener for items that are evicted from the cache. The listener
@@ -1137,9 +1142,12 @@
}
V old;
Entry<K, V> e = find(key, hash);
+ boolean existed;
if (e == null) {
+ existed = false;
old = null;
} else {
+ existed = true;
old = e.value;
invalidate(key, hash, RemovalCause.REPLACED);
}
@@ -1160,6 +1168,12 @@
mapSize++;
// added entries are always added to the stack
addToStack(e);
+ if (existed) {
+ // if it was there before (even non-resident), it becomes hot
+ if (PUT_HOT) {
+ access(key, hash);
+ }
+ }
return old;
}
{noformat}
Second part (oak-segment-tar), not sure if that's needed:
{noformat}
--- src/main/java/org/apache/jackrabbit/oak/segment/SegmentCache.java
(revision 1764860)
+++ src/main/java/org/apache/jackrabbit/oak/segment/SegmentCache.java
(working copy)
@@ -67,16 +73,20 @@
this.cache = CacheLIRS.<SegmentId, Segment>newBuilder()
.module("SegmentCache")
.maximumWeight(cacheSizeMB * 1024 * 1024)
+ .stackMoveDistance(1)
+ .segmentCount(4)
.averageWeight(Segment.MAX_SEGMENT_SIZE / 2)
.weigher(weigher)
{noformat}
> Too many segment cache misses
> -----------------------------
>
> Key: OAK-4936
> URL: https://issues.apache.org/jira/browse/OAK-4936
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Labels: performance
> Fix For: Segment Tar 0.0.16
>
> Attachments: OAK-4936-monitoring.patch
>
>
> Running the {{ConcurrentWriteTest}} benchmark and monitoring the hits and
> misses of the segment cache (LIRS), I noticed that some segments are loaded
> over and over again (up to 3000 times).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
