Tuning garbage collection (GC)
Jira applications are robust applications that rarely require in-depth garbage collection (GC) tuning. However, on large-scale installations, GC tuning can improve the performance of Jira applications. Analysis of GC logs can also assist in troubleshooting performance problems. This page lists basic recommendations that improve garbage collection, and is an entry point to the advanced GC Tuning Guide. The recommendations are based on Support's successful experiences with customers with large Jira instances.
You should get yourself familiar with garbage collection if:
- Jira has high memory or CPU consumption, or
- Jira is performing slowly or has occasional outages
Tuning garbage collection
Checking the GC performance
The first step towards improving GC is actually measuring the GC performance of the JVM to see the size of the problem. You can do it by viewing and analyzing the GC logs. The logs indicate when the JVM is collecting garbage, how long this process takes, and how much memory has been freed. Starting from Jira 7.4, GC logs are generated automatically, and you can find them in <installation-directory>/logs. GCViewer is a great tool for analyzing GC logs. To enable garbage collection in earlier Jira versions, see Using garbage collection logs.
Garbage Collectors
Don't use the Concurrent Mark Sweep (CMS) Collector unless otherwise adviced by Atlassian Support. It requires extensive manual tuning and testing, and is likely to result in degraded performance. Instead, we recommend that you use Garbage First Garbage Collector (G1GC), especially if your heap is larger than 6 GB.
Heap size
Start with the smallest heap possible, and increase it in 512 MB or 1 GB allotments when you experience OutOfMemory errors or run into any memory-related problems. Do not increase the heap further than required, as this will result in longer garbage collection. After garbage collection, the memory used should be 1/3 the size of the total heap, and that's your goal.
Old tuning parameters
On every full garbage collection, 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.
VM resources
If you run Jira on a VM, check that it's not using the swap file. If it does, during the garbage collection, the JVM 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, we recommend following the instructions in our Garbage Collection (GC) Tuning Guide. This document will take you through the process of choosing performance goals (throughput/footprint/latency), and how to tune for these goals.