Managing Confluence's performance and memory usage really depends on what resources are available - Confluence will run faster if you give it lots of memory for its caches, but it should still be able to run quite well in low-memory environments, with the right tuning. Below are some tips on getting the most out of your Confluence site:

Increasing the amount of memory available to Confluence

See Increasing JIRA Memory for details on how to increase the memory available to web application servers typically used to run Confluence.

Embedded Database

The embedded HSQL database that comes with Confluence essentially holds all your data in memory while the Confluence server is running. If you are running out of memory, you should consider migrating Confluence to some external RDBMS.

Caching

By default, Confluence keeps large in-memory caches of data to improve its responsiveness and the user experience. The trade off is an increase in memory requirements to support the cache. The default size of these caches will be reduced significantly in Confluence 1.5 (although this means that administrators of larger Confluence sites may need to configure the size of their caches to improve performance).

To customise confluences cache to meet your needs, see cache tuning.
To increase the amount of memory available to confluence, see allocating more memory to tomcat.

Mail error queue

Confluence keeps a copy of all emails that it failed to send within an internal error queue. In the event of intermittent failures such as network connectivity issues, the emails in this queue can be manually resent when the problem is fixed. Under certain circumstances, the mail queue can fill up with large objects. Since Confluence 1.4.1 the queue is regularly flushed, but if you get a lot of mail errors, you might get a spike in memory usage.

Attachments

The indexing of large attachments requires that the attachment be loaded into memory. In the case of large attachments, this can cause a temporary strain on the systems resources, and may result in indexing failing because the attachment could not be fully loaded into memory.

System backup / resort

The Confluence backup and resort process scales linearly with the size of data. This can have a significant impact on large Confluence instances where the amount of data exceeds the amount of available memory. If you are experiencing OutOfMemoryErrors during either a backup or restore, you with either need to move to per space backups or increase the memory allocated to Confluence. This is addressed in the upcoming Confluence 2.0.

If you are attempting to restore a backup and encountering the OutOfMemoryError, how much memory will you need to make it work? A good rule of thumb is to have a look at the size of the entities.xml file in your backup. This file contains all of the data Confluence will be loading, so at least that much is required. Add another 64-128Mb to ensure that Confluence has enough memory to load and function and that should be enough.

This problem has been resolved in Confluence post 1.4.x. To increase the amount of memory available to confluecne, see allocating more memory to tomcat.

Known issues that we do not have control over.

There are also some memory issues we don't have any control over. For example,

  • There's a memory leak in the Oracle 10g JDBC drivers. Not much we can do about that.
  • one customer found a rather nasty memory leak that appeared to originate inside Tomcat 5, but only using the IBM JDK on PowerPC.

If you're having problems that appear to be a memory leak, file an issue on http://support.atlassian.com. Our memory profiler of choice is YourKit, so if you can get a memory dump from that tool showing a leak

Confluence is taking long periods of time to respond to some actions

A common cause of random pauses in Confluence is the jvm running garbage collection. To determine if this is what is happening, enable verbose garbage collection and look at how long java is taking to free up memory. If the random pauses match when java is running its garbage collection, garbage collection is the cause of the pause.

Verbose garbage collection will generate log statements that indicate when java is collecting garbage, how long it takes, and how much memory has been freed. You can enable verbose garbage collection by specifying the -verbose:gc jvm option. To have the garbage collection logs written to a file, use -Xloggc:<filename>

What can you do to minimise the time taken to handle the garbage collection? See http://java.sun.com/docs/hotspot/gc1.4.2/ for details on tuning the jvm to minimize the impact that garbage collection has on the running application.

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.