JVM memory tuning for eXist

Question

Suppose you had a server with 24G RAM at your disposal, how much memory would you allocate to (Tomcat to run) eXist?

I'm setting up our new webserver, with an Intel Xeon E5649 (2.53GHz) processor, running Ubuntu 12.04 64-bit. eXist is running as a webapp inside Tomcat, and the db is only used for querying 'stable' collections --that is, no updates are being executed to the resources inside eXist.

I've been experimenting with different heap sizes (via -Xms and -Xmx settings when starting the Tomcat process), and so far haven't noticed much difference in response time for queries against eXist. In other words, it doesn't seem to matter much whether the JVM is allocated 4G or 16G. I have also upped the @cachesize and @collectionCache in eXist's WEB-INF/conf.xml file to e.g. 8192M, but this doesn't seem to have much effect. I suppose these settings /do/ have an influence when eXist is running inside Tomcat?

I know each situation is different (and I know there's a Tomcat server involved), but are there some rules of thumb for eXist performance w.r.t. the memory it is allocated? I'd like to get at a sensible memory configuration for a setup with a larger amount of RAM available.

Answer 1

This question was asked and answered on the exist-open mailing list. The answer from wolfgang@exist-db.org was:

Giving more memory to eXist will not necessarily improve response times. "Bad" queries may consume lots of RAM, but the better your queries are optimized, the less RAM they need: most of the heavy processing will be done using index lookups and the optimizer will try to reduce the size of the node sets to be passed around. Caching memory thus has to be large enough to hold the most relevant index pages. If this is already the case, increasing the caching space will not improve performance anymore. On the other hand, a too small cacheSize of collectionCache will result in a recognizable bottleneck. For example, a batch upload of resources or creating a backup can take several hours (instead of e.g. minutes) if @collectionCache is too small.

If most of your queries are optimized to use indexes, 8gb RAM for eXist does usually give you enough room to handle the occasional high load. Ideally you could run some load tests to see what the maximum memory use actually is. For @cacheSize, I rarely have to go beyond 512m. The setting for @collectionCache depends on the number of collections and documents in the database. If you have tens or hundreds of thousands of collections, you may have to increase it up to 768m or more. As I said above, you will recognize a sudden breakdown in performance during uploads or backups if the collectionCache becomes too small.

So to summarize, a reasonable setting for me would be: -Xmx8192m, @cacheSize="512m", @collectionCache="768m". If you can afford giving 16G main memory it certainly won’t hurt. Also, if you are using the lucene index or the new range index, you should consider increasing the @buffer setting in the corresponding index module configurations in conf.xml as well:

<module id="lucene-index" buffer="256" class="org.exist.indexing.lucene.LuceneIndex" />
<module id="range-index" buffer="256" class="org.exist.indexing.range.RangeIndex"/>