SonarQube v8.9.10 - Enterprise Edition - Sonarqube Task has increased from 5 mins to 20 mins

SonarQube Server / Community Build
,
1

Hi,
We recently upgraded from SonarQube version 7.9.1 community edition to version 8.9.10 enterprise edition and deployed it via the .zip file from downloads section on sonarsource.
Upon release documentation I copied over the memory allocations from sonar.properties on version 7.9.1 manually over to version 8.9.10 also using SQLServer DB.

We have a gradle built application via cloudbees jenkins that has approx 400k LOC and the sonarqube task is now taking 20 mins where on SonarQube version 7.9.1 community edition it was taking 5 mins.

I have tried increasing the workers but only slows it down even more.

Below are the existing memory allocations for Web & Compute Engine that I have set on SonarQube version 8.9.10 enterprise edition.

sonar.web.javaOpts=-Xmx1024m -Xms512m -XX:+HeapDumpOnOutOfMemoryError
sonar.ce.javaOpts=-Xmx2048m -Xms512m -XX:+HeapDumpOnOutOfMemoryError

Attaching logs, fyi they are set at INFO Level, if they need changing to DEBUG let me know.

The issue is with project named “qps-ui-case-sandbox”
Started: 13:28:30 > Task :sonarqube:
Finished: 13:47:14
sonar.log (3.0 KB)
es.log (4.7 KB)
ce.log (99.9 KB)

Any help would be appreciated.

Thanks,
Brendan

5

Hey there.

Congratulations on making the step from SonarQube v7.9 LTS to v8.9 LTS. Before troubleshooting performance, I have to suggest that you move to SonarQube v9.9 LTS which is the minimum supported version of SonarQube.

Your upgrade path is:

8.9.10 → 9.9.3 → 10.3 (last step optional)

You may find these resources helpful:

If you have questions about upgrading, feel free to open a new thread for that here.

If your issue persists after upgrade, please come back to us. It also looks like the ce.log file you shared don’t contain any tasks that took longer than 2 minutes for a branch analysis, and 4 seconds for a pull request analysis. Once you’ve upgraded, make sure the logs contain the relevant compute engine task.

6

Hi Colin,

Thanks for the reply.

We pass in the sonarqube task into our cloudbees jenkins build.gradle task and because of the multi branch SCM Artifactory Plugin that’s no longer supported those maven builds locks us on jdk8 on cloudbees which locks us on version 8.9 on sonarqube. As our cloudbees build agent on Java17 cannot initiate sonar scanner on java17 on sonarqube version 9.4 as we had to roll that back to 8.9.

Is it worth looking at our linux red hat 8 sonarqube server setup, CPU, swap/heap space, memory allocation?

I checked our MS SQL Server and memory is more than enough currently.

In terms of the ce.log thats correct the longest executing task was approx 2 mins and that was only a few, the rest were in ms.

Any suggestions?

Thanks,
Brendan

7

Okay – perhaps I misunderstood (although at its core, my advice is the same) – it’s right that the time is being taken by the gradle scanner and not by SonarQube itself? In that case, there’s nothing to look at regarding SonarQube server configuration (memory, database, etc.)

Java 11 is required for the scanner runtime for SonarQube v9.9 LTS, and it should be possible to execute the gradle scanner with a different version of Java than you build with. See the example in the Scanner Environment documentation:

# Gradle build
gradle build ...
export JAVA_HOME=/path/to/java-11-or-17
gradle sonarqube ...

And I still can’t reccomend troubleshooting performance issues on anything but a supported version of SonarQube. There have been a huge number of performance improvements made in between SonarQube 8.9 LTS and 9.9 LTS, and that should become the baseline for any furhter troubleshooting (if it’s required at all).