To keep SonarQube running at peak performance, it is important to allocate enough memory to the JVM processes that SonarQube runs on your host. This guide will provide some direction on what settings to use.
-
The configuration file where these settings can be found is located under
$YOUR_SONARQUBE_INSTALL_DIR/conf/sonar.properties(replace $YOUR_SONARQUBE_INSTALL_DIR with the directory where SonarQube is actually installed. Before making any modification to the sonar.properties file, it is a good practice to make a backup of it). -
Inside the sonar.properties file, the default setting is shown as a comment, for instance
#sonar.web.javaOpts=-Xmx1G
Uncomment this line to change this default setting, for instance to
sonar.web.javaOpts=-Xmx2G
DISCLAIMER: Actual settings are dictated by your organization’s usage of SonarQube, these guidelines are intended to be a starting point that should be adjusted based on observations from monitoring of your instance. Our Monitoring documentation recommends techniques to monitor memory (and other resource) usage of your SonarQube instance.
Web Server - sonar.web.javaOpts
The Web process serves the UI and handles API requests. OutOfMemoryErrors in web.log indicate a requirement for additional memory to this process.
- Baseline: -Xmx1G
- If your SonarQube instance is supporting a high number of users (1000s) or heavy usage of the web API, increase this value to -Xmx2G
Compute Engine - sonar.ce.javaOpts
The Compute Engine process handles incoming analyses. Background Tasks failing with OutOfMemoryErrors are a clear indicator that additional memory is needed for this process.
- Baseline: -Xmx1G
- Increase based on size of the largest project that you’re scanning (in LOC)
- Largest project > 1M lines of code, -Xmx2G
- Largest project > 5M lines of code, -Xmx3G
- Enterprise and Data Center Edition only: if you have increased your Worker count, multiply your -Xmx value by the number of Compute Engine Workers.
To find the largest Project on your SonarQube server in terms of LOC, you can sort by size from the Projects page.
Additional information is available on the Compute Engine Performance section of the SonarQube documentation.
Search Server - sonar.search.javaOpts
The Search process acts as a cache for the information in SonarQube. Slow processing of Background Tasks and/or sluggish performance of the UI are indicative of a lack of memory allocated to this process.
- Baseline: -Xmx2G -Xms2G
- -Xmx and -Xms values must be the same to avoid heap resizes
- General rule is to allocate memory based on the current size of search indexes plus headroom for growth (an additional 1GB provides an adequate buffer)
- Must be no more than 30GB and no more than half the total RAM of the machine
You can find the current size of your search index listed as “Store Size” in Administration > System > Search Engine.
It goes without saying that the total memory allocated to these SonarQube processes should be less than the physical memory available on the host (less memory needed for the OS and other processes).