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
