This page last changed on Jul 26, 2009 by ggaskell.

The minimum and maximum JVM heap space allocated to the application server affects performance. Confluence administrators may wish to modify this value from the defaults depending on their server load. This document only provides guidelines rather than rules, so administrators optimising for performance should use this document as a starting point only.

Testing For Optimum Memory Settings

Bigger is not always better for heap size. When optimising memory settings, consider starting by setting the minimum heap size to 1/4 the available physical memory on the server and setting the maximum to 1/2 of the maximum heap. Avoid setting the minimum and maximum to be the same since server load is normally variable. Being able to use less memory under low load results in slightly improved performance as garbage collections can be made smaller.

Testing Resources

  • Enable the verbosegc JVM parameter to assist in determining the memory size that minimises overall garbage collection
  • Use Page Request Profiling to gauge end-user performance

Determine Minimum Memory
Experiment with setting a lower minimum such as 1/10 of the maximum heap. Identify how much memory is required while under minimum load and set the minimum to that value. It is important to have Confluence use the minimum memory necessary, because garbage collection performance is dependent on the memory usage. Having an unnecessarily high minimum memory setting will degrade performance during GC operations.

Determine Maximum Memory
Experiment with different maximum memory settings with the verbosegc JVM parameter enabled to determine GC performance. Memory usage is most likely to be maximised under peak load, and when creating a site XML backup.

Atlassian recommends disabling the XML backup and using the Alternative Backup Strategy.

  • If you normally perform manual XML site backups on your server, test your maximum memory requirements by performing a site XML backup while the server is under maximum load
  • If you do not create manual XML site backups, simply monitor the server while under maximum load

The maximum memory should be the total memory while in this state plus a buffer of at least 15%, taking into account how your garbage collection performs. Never set maximum memory to a value above 85-90% of the available physical server memory as this results in disk paging. Always leave 10-15% of available physical server memory unallocated to allow for OS background processes.

Applying Memory Settings

Users of the EAR/WAR distribution set their memory in their application server. For Confluence Standalone, the heap space is set in the Confluence install directory.

  • Windows users edit TOMCAT_HOME/bin/setenv.bat
  • Other OS users edit TOMCAT_HOME/bin/setenv.sh

If you are running Tomcat as a Windows service, you may need to run a regedt32 to increase memory as in the article on increasing JIRA memory. Although the article discusses JIRA, it should also be applicable to Confluence.

The relevant parameter is

JAVA_OPTS="-Xms256m -Xmx1024m"

Where -Xms is the minimum and -Xmx is the maximum memory available to Apache Tomcat. In this sample the maximum memory has been set to 1024 megabytes, but you will have to figure out the best setting based on your particular environment.
Note: In newer Tomcat distributions the file may not exist. Feel free to create it in the ./bin directory.

Additional Suggestions

Upgrade to Java 6
Java 6 has some better reporting when it comes to memory management, also Java 5 is almost out of life for Sun as Java 6 has been out for quite some time (over 2 years!). If upgrading to 6 is not an option, upgrading to a more recent Java 5 is highly recommended, there is an Java 5 update 15 (they are running a BETA of update 8).

Tune the garbage collector
There is a very overly complicated document on tuning the garbage collector on Java 6 (Java 5 version). This document will probably be a bit overwhelming, the only thing that really could be experimented with is selecting a different collector as the default one can cause system pauses while it finds collectible memory.

Make memory sizes equal
If you set the initial memory allocation size (-Xms) and the max memory allocation size (-Xmx) the same you can reduce overhead in the JVM because it doesn't need to resize the memory. This doesn't always result in performance improvements though.

PermGen Memory
The Permanent Generation Size -XX:MaxPermSize=128m could be increased but only really needs to be if they experience OutOfMemoryErrors which are reported to be PermGen full errors. 128m does seam a little low for this, especially on a 64bit JVM, but increasing it won't directly affect performance (just stopping a crash when it fills up).

Stack Size
Setting the stack size (-Xss) is ok, but can result in the JVM requiring more memory. Decrease it if you are running out of heap.

Related Topics

Document generated by Confluence on Nov 05, 2009 23:34