Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <14231342.1193230010661.JavaMail.jira@brutus>
Date: Wed, 24 Oct 2007 05:46:50 -0700 (PDT)
From: "Martijn Hendriks (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-937) CacheManager max memory size
In-Reply-To: <4577932.1179851476264.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537307 ] 

Martijn Hendriks commented on JCR-937:
--------------------------------------

Ard, thanks for your explanation. I think you are right that a more efficient Lucene configuration would let the test pass. If I add 1000 String properties of approx 1 MB (with max 512 MB heap space) then the OOM will reappear because Jackrabbit then tries to cache all these properties due to underestimation of the retained memory of the caches. I will create a separate issue for this.

> CacheManager max memory size
> ----------------------------
>
>                 Key: JCR-937
>                 URL: https://issues.apache.org/jira/browse/JCR-937
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.3
>            Reporter: Xiaohua Lu
>            Assignee: Thomas Mueller
>            Priority: Minor
>         Attachments: CacheManagerTest.java
>
>
> I have ran into OutOfMemory a couple of times with Jackrabbit (cluster, 4 nodes, each has 1G mem heap size). 
> After adding some debug into the CacheManager, I noticed that maxMemorySize (default to 16M) is not really honored during resizeAll check.  Each individual MLRUItemStateCache seems to honor the size, but the total number/size of MLRUItemStateCache is not. If you put some print statement of totalMemoryUsed and unusedMemory, you can see that totalMemoryUsed is more than 16M and unusedMemory is negative. 
> The other problem we have noticed during the profiling is there are a lots of other in memory objects that are consuming memory but not included in CacheManager caches control. One example is CachingHierarchyManager which consumed 58M out of 242M through its use of PathMap. If CacheManager's maxSize can control the total cache size used by Jackrabbit, that would be easier from a management's perspective. (btw, upper_limit in CachingHierarchyManager is hardcoded and can't be control from outside)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.