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.
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.
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:
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]
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:
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
Can you add -Dsonar.verbose=true to your analysis command line and post the resulting analysis log, redacted as necessary?
Thank you very much for your hints. For long building time, once I get debug log information, I will feedback to you.
For the other 2 problems,I will test your suggestion. If problem still persists, I will open a new topic separately.
I’ve uploaded the log file generated with the -Dsonar.verbose=true flag for maven goal: mvn sonar:sonar consoleText.zip (250.5 KB).
I hope this provides some helpful clues for further investigation. Thank you!
Thanks for the log. Unfortunately, this is not a debug log, so it’s not giving the low-level timings I was looking for. Can you add -Dsonar.verbose=true to your analysis command line and provide that log, please?
The previous log file is from a build that already had -Dsonar.verbose=true set, but it seems that didn’t enable debug mode in our case. I added the -X flag to the Maven command, and now I can see [DEBUG] messages in the output. Hopefully, this time you’ll be able to gather some useful information. consoleText.zip (16.9 MB)
Thanks for the log. Not much is jumping out at me here (altho in a nearly 2M-line log, that would be hard ). Nothing seems to be taking an egregious amount of time. It’s just that there’s a lot going on.
Purely as a side-note, I see this in your analysis command: -Dsonar.language=java. That option hasn’t done anything for nearly a decade now. You can remove it.
Similarly, in a Maven analysis, this isn’t really necessary: -Dsonar.inclusions=**/*.java . Altho I do understand keeping the analysis narrowed as much as possible in this context.
But I’m bike-shedding…
I do notice that you’re using the Sonargraph plugin. Would it be possible to remove it and any other 3rd-party plugins - at least temporarily - and reanalyze to see if that makes a significant difference? Based on the log I don’t expect it to, but I need to cross that off the list.
I need to ask the dumb question. You started by saying the project has 3.5M LOC… It already had 3.5M LOC when you were on 9.9, right? You didn’t add 1M LOC right around the time of the upgrade?
Just for your questions-no, the project hasn’t grown, it is 3.5M LOC most of time.
Last days we also increase the resource of database of sonarqube, but it doesn’t help.
Currently the scanning time is around 4.5 to 5 hours. Does any other customer report similar problem?
