Performance issues
Steps to consider when addressing performance issues.
In case of performance issues, you may try the following:
Review the Server host requirements for SonarQube Server linked to Elasticsearch usage.
Move the Elasticsearch storage to a storage with high IOPS and low latency. See Configure the Elasticsearch storage path for more information.
Set the Housekeeping with a reduced retention time, to limit the database size.
Configure the analysis scope to reduce the number of files analyzed, leading to shorter analysis and smaller database footprint. See Introduction for more information.
From the Enterprise Edition: increase the number of Compute Engine workers and/or configure the Compute Engine to enable parallel processing of pull requests and branch analyses for each project. See Improving performance.
For the Data Center Edition on Kubernetes: set up autoscaling. See Setting up autoscaling for more details.
If performance issues occur after a PostgreSQL database upgrade, try reindexing the following database tables: issues, rules, and components.
Troubleshooting background tasks processing problems
You detected one of the following conditions:
Background tasks have been waiting in the queue longer than expected
Too many tasks are pending in the queue
A high share of background tasks are failing
Pipeline failures due to quality gate timeout, resulting from excess background task processing
All four signal the same class of problem: the Compute Engine (CE) is unable to process analyses at its normal rate. This guide walks you through diagnosing and fixing the most common causes.
Step 1. Understand what is happening
Go to Administration > Projects > Background tasks to see the current queue state:
How many tasks are pending and how long the oldest one has been waiting
Whether tasks are failing, and if so, which projects
Go to Administration > System to check the health of the Compute Engine, Web, and Search nodes.
If tasks are failing, click on a failed task to read the error message, this often points directly to the cause.
Step 2. Check heap size
In sonar.properties (or environment variables), verify:
sonar.ce.javaOptscontains an-Xmxvalue of at least 512 MB per worker.sonar.ce.workerCount× per-worker heap ≤ total RAM available after Web and Search allocations
Correct sizing:
CE
512 MB–2 GB × number of workers
Search (DCE)
2–4 GB
If you recently increased sonar.ce.workerCount without adjusting sonar.ce.javaOpts, that is almost certainly the cause. Reduce the worker count or increase Compute Engine heap, then restart.
Maven scanner users: If you upgraded the SonarQube Maven plugin to v5.0 or later, MAVEN_OPTS no longer controls scanner heap. Use SONAR_SCANNER_JAVA_OPTS instead.
Step 3. Check database performance
Database I/O problems are the second most common cause.
Check ce.log for slow steps. If you see any of the following taking more than a few minutes, the database is the bottleneck:
Persist issuesPersist live measuresExecute component visitors
Run database maintenance if it has not been done recently.
Also check storage write latency, SonarQube requires < 10 ms per write transaction. NFS or EFS mounts and spinning disks do not meet this requirement.
Step 4. Check for a large project blocking the queue
A single project with tens of thousands of components can monopolize Compute Engine for 30-60+ minutes. In Administration > Projects > Background tasks, look for one task that has been running much longer than the others.
If found:
Consider cancelling it and re-triggering after fixing heap or DB (see steps 2-3)
Review sonar.exclusions in that project's settings, generated code, test fixtures, dependencies, and build artifacts should be excluded
Step 5. For Data Center Edition
Verify every application node has at least one CE worker configured. A single shared worker across the cluster will cause queue buildup.
After a rolling restart, confirm all nodes have rejoined the Hazelcast cluster (Administration > System > Cluster) before triggering new analyses.
If you see Task does not exist anymore errors, this is a known race condition, failed tasks can safely be re-triggered.
Still not resolved?
Related pages
Last updated
Was this helpful?