Garbage Collector Performance Issues
The information on this page relates to memory management with Oracle's Hotspot JVM. These recommendations are based on our support team's successful experiences with customers with large Confluence instances.
Which garbage collector?
Confluence uses the garbage first garbage collector (G1GC) by default. This is the garbage collector we recommend.
See Garbage First Garbage Collector Tuning in the Oracle documentation for useful information on tuning this garbage collector.
We have also observed that G1GC performs better with a larger heap (2gb). See the information below about how to increase your heap size gradually.
Don't use the Concurrent Mark Sweep (CMS) Collector with Confluence, unless advised by Atlassian Support. It requires extensive manual tuning and testing, and is likely to result in degraded performance.
Use the right size heap
Keep your heap as small as possible, without the instance experiencing OutOfMemory errors. If you experience OutOfMemory errors and need to increase this, we recommend you do it in 512mb or 1gb allotments, and monitor the instance. If you continue to receive OutOfMemory errors, increase the heap by another 512mb or 1gb, and continue this process until you are operating stably with no OutOfMemory errors. Do not increase the heap further than required, as this will result in longer garbage collections.
Remove any old tuning parameters
On every full GC, the JVM will resize the allocations of Eden, Survivor etc based on the throughput it is actually seeing. It will tune itself based on the real world data of the objects that are being created and collected. Most of the time simply allowing JVM to tune itself will give you better performance.
If you have added JVM parameters in the past and are experiencing difficulties with GC now, we'd recommend you remove all GC related parameters, unless you added them to solve a specific problem, and they did in fact solve that problem. You should also consider re-benchmarking now to ensure that they are still solving that problem, and are not causing you any other issues.
Check your VM resources
If you run Confluence on a VM, check that is it not using the swap file. If it does, when the JVM garbage collects it has to load the objects from the swap file into memory to clean them, and this can cause significantly longer GC pauses. Instead of using swapping, ballooning and bursting, allocate adequate memory to the VM.
Manual Tuning
If you find you are still experiencing difficulties with GC after following these recommendations and you would like to see if you can tune the JVM better to improve performance, see our Garbage Collection (GC) Tuning Guide. This document was put together a few years ago, but has some useful information on choosing performance goals (throughput/footprint/latency), and how to tune for those goals.
Viewing your GC logs
How to Enable Garbage Collection (GC) Logging, and use a tool like Chewiebug's GCViewer to view the resulting logs.