jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Sutton <adr...@symphonious.net>
Subject Re: Jackrabbit In Low Memory Situations
Date Tue, 26 Jun 2007 07:47:07 GMT
Hi Thomas and Felix,
Thanks for your help, this gives me a few things to go on.

> - Transient changes / large transactions. Jackrabbit currently keeps
> unsaved changes in memory. I suggest you call Session.save from time
> to time in a large import.

We were calling session.save after every page (which is slowing  
things down, but not solving the problem outright). We weren't  
logging out and back in to create a new session though. Either way,  
the import isn't a problem as we can do it on a system with more  
memory available and it's only a once off operation anyway.

> - Caches from persistence managers (Derby uses a lot of memory)

This sounds like a promising lead - we want to evaluate switching to  
using MySQL instead of Derby since we already have the MySQL server  
anyway and we have the backup procedures in place for them. Sounds  
like it has potential to reduce our memory woes as well.

This gives me a bunch of other configuration options that I can tweak  
to get an idea of their effects as well which is very helpful. I've  
also managed to get some rough profiling results and tweaked things  
to pull less information out of the repository for each request which  
has gotten things to a reasonable point. With a few more tweaks in  
the right places it should be fast enough.

Thanks for the help.

Regards,

Adrian Sutton
http://www.symphonious.net



On 26/06/2007, at 4:52 PM, Thomas Mueller wrote:

> Hi,
>
> I don't think the Jackrabbit internal cache is the problem in your
> case. Usually the main reasons for memory problems are (as Felix
> wrote):
>
> - Transient changes / large transactions. Jackrabbit currently keeps
> unsaved changes in memory. I suggest you call Session.save from time
> to time in a large import.
>
> - Caches from persistence managers (Derby uses a lot of memory)
>
> To find out what component uses the most memory, I suggest you use a
> tool such as the YourKit Java Pofiler (free trial and open source
> licenses available).
>
> Jackrabbit internal caching: Yes, this is configurable. There was a
> patch for Jackrabbit 1.3, see
> http://issues.apache.org/jira/browse/JCR-725. The configuration is
> Jackrabbit specific:
>
> CacheManager manager = ((RepositoryImpl) repository).getCacheManager 
> ();
> manager.setMaxMemory(8 * 1024 * 1024); // default is 16 * 1024 * 1024
> manager.setMaxMemoryPerCache(1024 * 1024); // default is 4 * 1024 *  
> 1024
> manager.setMinMemoryPerCache(64 * 1024); // default is 128 * 1024
>
> The default values should be OK for most situations.
>
> Thomas


Mime
View raw message