[ 
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)

Reply via email to