SonarQube Performance Tuning
A fast SonarQube server keeps developers happy. Slow pages and long queues push teams to skip scans, which defeats the purpose. Most performance problems trace back to memory limits, slow disks, or a crowded database. Simple measurements point to the right fix.
The Highway Picture
Traffic jams appear at narrow spots, not everywhere. Widening the wrong road wastes money. Tuning SonarQube works the same way: find the narrow spot first.
Scanner ──► Web Server ──► Compute Engine queue ──► Compute Engine ──► Database
│ │
slow pages? long queue?
→ web memory → CE memory / workers
slow saves?
→ database / disk
Know the Three Memory Areas
SonarQube runs three Java processes. Each process has its own memory limit in conf/sonar.properties.
| Process | Property | Handles |
|---|---|---|
| Web Server | sonar.web.javaOpts | Pages and API requests |
| Compute Engine | sonar.ce.javaOpts | Analysis processing |
| Search Server | sonar.search.javaOpts | Issue search and indexes |
Example Settings
sonar.web.javaOpts=-Xmx1g -Xms512m sonar.ce.javaOpts=-Xmx2g -Xms512m sonar.search.javaOpts=-Xmx2g -Xms2g
The letters Xmx set the maximum size. Xms sets the starting size. Give the search server the same value for both.
Match Memory to Size
Larger codebases and more projects need more memory. Sonar documents recommended sizes by lines of code. Leave plenty of memory for the operating system, because the search server relies on the file system cache.
Find the Bottleneck
- Open Administration, then Projects, then Background Tasks.
- Check the queue length and the time each task takes.
- Open the system information page to review memory use per process.
- Read the logs for out-of-memory messages.
Common Slow Spots and Fixes
Long Task Queue
Many pipelines finishing at once overload a single Compute Engine worker. Raise the Compute Engine memory first. Higher editions allow several workers that process reports in parallel.
Slow Search Pages
Move the search data folder to a solid-state disk. Increase the search memory in small steps and watch the effect.
Slow Saves and Slow Dashboards
Check the database server. Give it enough memory, fast storage, and a location close to SonarQube on the network.
Reduce the Load
- Exclude generated code, build output, and vendor libraries from analysis.
- Skip analysis of long-lived branches that nobody reads.
- Spread scheduled scans across the night instead of starting them together.
- Remove old projects that no team uses.
Use Housekeeping
Every analysis stores a snapshot. Old snapshots add weight to the database and slow reports. Open Administration, then Configuration, then General Settings, then Housekeeping. Set shorter retention for daily snapshots and keep important version snapshots longer.
Scanner-Side Tuning
Slow analysis can start on the build machine. Large projects benefit from a bigger scanner memory limit.
export SONAR_SCANNER_OPTS="-Xmx2g"
Caching the scanner folder between pipeline runs reduces download time.
Change One Thing at a Time
Adjust a single setting, restart, and measure again. Writing notes about each change helps you undo mistakes and teaches the team what works for your workload.
Common Mistakes
- Giving all server memory to Java and starving the operating system.
- Running the database on a slow shared disk.
- Raising limits without checking logs for the real error.
A Tuning Example
A company notices that morning analysis tasks wait twenty minutes in the queue. The Background Tasks page shows many reports arriving together at nine o'clock. The administrator raises the Compute Engine memory, staggers two heavy nightly pipelines, and excludes generated code from the largest project. The queue shrinks to two minutes. Three small changes beat any single dramatic one.
Quick Recap
Measure the queue, adjust the memory of the right process, use fast storage, trim old data, and exclude files that add no value. Small targeted changes beat large guesses.