Sonarqube is very slow after upgrade to 8.4.1

SonarQube
1

we are using community edition upgraded sonarqube from 7.7 version to 8.4
It is a java project with 730k LOC , using sonar scanner 4.5 version for jenkins.
Database is postgres 10.11 version.Java code analyser version is 6.5.1, the analysis time is 10-12 hrs.

Previously when we are using 7.7 the scan was completed in 2 hours.

Tried the full vacuum on postgres and reindexing of elastic search but no luck

Executed in Virtual machine (16GB) OS : Oracle Linux
sonar.web.javaOpts
sonar.ce.javaOpts
sonar.search.javaOpts

Kindly suggest memory options to improve the performance (t

4

Hi,

After upgrading from SonarQube 7.7 to 8.4, not only the SonarQube server has been upgraded but also the language analyzers.
The time of analysis can be seen as:

  1. The time of each language analyzer to analyze the code. It is usually the bottleneck.
  2. The time spent by the scanner to send all the issues to SonarQube. Could only be slow if there are several millions of issues…
  3. The time for SonarQube compute engine to make the analysis available on its website. I assume it’s out of scope from the slowness that you are reporting.

So first, we need to find which stage is the slowest. Because if the problem is on one language analyzer side (part of the continuous integration), then it useless to try to improve SonarQube server memory settings.

Could you try to look at the time information in the analysis console?
For example:

# if you have saved your scanner logs in an analyze.log file
$ grep 'time=' analyze.log
...
INFO: Sensor JavaSquidSensor [java] (done) | time=210234ms
INFO: Sensor CSS Rules [cssfamily] (done) | time=3ms
INFO: Sensor C# Properties [csharp] (done) | time=0ms
INFO: Sensor SurefireSensor [java] (done) | time=0ms
INFO: Sensor JavaXmlSensor [java] (done) | time=16ms
INFO: Sensor HTML [web] (done) | time=4ms
...

In your case, you could probably filter by time with at least 6 digits:
$ grep -E 'time=[0-9]{6,}ms' analyze.log

Then if the analysis stays more than 10 seconds on a file, you can have duplicated lines like:

$ grep -E 'files analyzed, current file:' analyze.log
...
INFO: 1931/5345 files analyzed, current file: src/javax/xml/catalog/GroupEntry.java
INFO: 1931/5345 files analyzed, current file: src/javax/xml/catalog/GroupEntry.java
...

You can find them using:

$ diff <(grep -E 'files analyzed, current file:' analyze.log|sort) <(grep -E 'files analyzed, current file:' analyze.log|sort -u)
< INFO: 1931/5345 files analyzed, current file: src/javax/xml/catalog/GroupEntry.java

Could you share your bigger ‘time=’ log line?