Significant Increased Build Time After SonarQube Upgrade from 9.9 to LTA 2025.1

SonarQube Server / Community Build
,
1

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension)
    SonarQube Enterprise Edition LTA 2025.1
  • how is SonarQube deployed: zip, Docker, Helm
    zip
  • what are you trying to achieve
    Analyse Java project, ca. 3.5 M LOC
  • what have you tried so far to achieve this
    Call maven goal mvn sonar:sonar

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

Both the build server and the SonarQube server environments remain unchanged, except for the upgrade of SonarQube from version 9.9 to LTA 2025.1. However, we observed a significant increase in build time for the mvn sonar:sonar command—from approximately 1 hour to around 3 hours. Notably, the first run after the upgrade took nearly 5 hours, and subsequent runs have stabilized at about 3 hours.

Below are the Java options currently configured for both Maven and the SonarQube server.

mvn sonar:sonar java option:

MAVEN_OPTS="-Xms1G -Xmx10G -XX:ReservedCodeCacheSize=128m -XX:+UseCodeCacheFlushing

WEB SERVER

sonar.web.javaOpts=-Xmx8G -Xms8G -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=true -Djava.security.egd=file:///dev/urandom

COMPUTE ENGINE

sonar.ce.javaOpts=-Xmx2G -Xms128m -XX:+HeapDumpOnOutOfMemoryError

ELASTICSEARCH

sonar.search.javaOpts=-Xmx3G -Xms3G -XX:MaxDirectMemorySize=1G -XX:+HeapDumpOnOutOfMemoryError
sonar.search.javaAdditionalOpts=

Is there anything we can do to optimize or reduce the build time? Thank you in advance for your support.

2

Hi,

We’ve made significant improvements on what analysis can find since 9.9 and that, unfortunately, has had an impact on analysis duration.

You’ve shared the memory specs of both analysis and of the server. On which side are you seeing the bulk of the analysis duration increase? CI-side or server-side?

Regarding your server, I might shift some of the memory you’ve allocated to the web process to the compute engine instead. After all, the web server just serves web pages. The compute engine is where the heavy lifting happens.

 
HTH,
Ann

3

Hi Ann,

Thank you for your feedback.

As you suggested, we increased the CE heap size from 2G to 8G for 4 workers. This resulted in a slight improvement in background task performance. However, the main bottleneck is on the CI side.

We are using:

  • Apache Maven 3.8.8
  • sonar-maven-plugin:jar:4.0.0.4121

The current analysis time is:

[INFO] 09:24:17.136 Analysis total time: 2:49:55.386 s

Previously, with SonarQube v9.9, the analysis took less than 1 hour.

Additionally, we’ve encountered two more issues:

  1. Unstable CI-side error (approx. 1 in 5 builds):
    Even when the background task completes successfully, we sometimes get the following error:
   [ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121:sonar (default-cli) on project salog-aggregator: 
   Failed to upload report: Fail to request URL: 
   https://company.com/api/ce/submit?projectKey=com.kn%3Axxx%3Axxx&projectName=xxx%20xxx&characteristic=branch%3D4.27&characteristic=branchType%3DBRANCH
   : timeout -> [Help 1]
  1. Error in ce.log:
   2025.06.24 22:01:51 ERROR ce[][o.s.c.t.CeWorkerImpl] Failed to pop the queue of analysis reports
   org.apache.ibatis.exceptions.PersistenceException: 
   Error querying database. Cause: java.sql.SQLTransientConnectionException: 
   HikariPool-1 - Connection is not available, request timed out after 10002ms (total=3, active=2, idle=1, waiting=0)

We are using Oracle 19c , with the connection pool maximum set to 60 . Occasionally, this leads to background task failures due to connection timeouts. Below is the DB configuration in sonar.properties:

sonar.jdbc.maxActive=60
sonar.jdbc.maxIdle=5
sonar.jdbc.minIdle=2
sonar.jdbc.maxWait=10000

sonar.jdbc.minEvictableIdleTimeMillis=600000
sonar.jdbc.timeBetweenEvictionRunsMillis=30000

These may be three separate issues, but we’d appreciate your insights and support in resolving them.

Best Regards,
Lu Wang

4

Hi Lu,

As you note, these are 3 separate issues, and we try to keep it to one topic per thread. Otherwise it can get messy, fast. This thread should focus on the initial problem statement: CI-side analysis duration.

However, I will nonetheless take a quick pass.

This is happening in your proxy. As I said earlier, analysis is smarter now. That means it finds more → larger analysis report bundle to send to the server. So sometimes the analysis report size is exceeding your proxy’s limit. You need to talk to your proxy admins.

This is because the DB connection timeouts don’t match. Check the settings described here: SONAR-17762.

Now, getting back to the initial complaint :sweat_smile:

Can you add -Dsonar.verbose=true to your analysis command line and post the resulting analysis log, redacted as necessary?

 
Thx,
Ann

P.S. More on the JDBC settings in the docs.