jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: CacheManager (Memory Management in Jackrabbit)
Date Thu, 02 Nov 2006 09:07:38 GMT
On 11/2/06, Thomas Mueller <thomas.tom.mueller@gmail.com> wrote:
> Hi,
> Just recently I experienced an out of memory problem with Jackrabbit.
> I analyzed the memory usage and found the problem is the combined size
> of the various caches of Jackrabbit, and other libraries (Lucene, the
> database, and others). The biggest problem was the combined size of
> the o.a.j.core.state.MLRUItemStateCache caches. Each session seems to
> create a few (?) of those caches, and each one is limited to 4 MB by
> default. At one point, I had 16 of those. 64 MB is not that much, but
> if you only allocate 128 MB it is already a problem. It is possible to
> change the size limit (by changing DEFAULT_MAX_MEM), but this means
> the biggest one can get at most this amount of memory.
> I think that would be good is some kind of dynamic (cache-) memory
> management. A single service that distributes the available memory (or
> at least some fixed amount) dynamically to all those caches (let's
> call it CacheManager). This could be per-repository, or a singleton.
> It would keep a weak reference to all caches. If a new cache is
> created, the cache manager would give him some minimum amount of
> memory (let's say 128 KB), and if the cache is used frequently, it
> would get more memory. The cache manager would shrink caches that are
> not used frequently.
> I suggest to implement such a singleton CacheManager. Currently just
> for MLRUItemStateCache, as this seems to be the biggest problem so
> far. Later on (if we think it's worth doing it), it could be extended
> to other caches as well.

+1, sounds good

> Maybe such a service already exists somewhere (apache commons?) Please
> tell me if you know of any such service. If not, I will go ahead and
> implement such a feature, unless there are other ideas.

be aware that some of jackrabbit's internal caches have special semantics,
e.g. ItemStateReferenceCache has to make sure that there is at most
one item state instance per id (see javadoc for details). internally it uses
a MLRUItemStateCache as secondary cache which uses apache commons

a generic caching framework might not work.


> Thomas

View raw message