Compute Engine tasks are too slow

  • SonarQube Enterprise 8.9.0
  • SonarQube deployed on zip
  • Try to find why the step “Checks executed after computation of measures” is so slow
  • We have enabled DEBUG log level in compute engine but we cannot find anything. Nothing is logged between the previous step and the slowest step.

Hi all!

Thank you so much for the community support. We are having a performance issue on a large instance of SonarQube that is still on old LTS 8.9. Since it is a very big company the upgrade to the new LTS 9.9 is not so easy and will have to wait till the end of the year or maybe next year.

We don’t know why the step “Checks executed after computation of measures” is so slow (22 minutes). This is a sample log of a compute engine task:

09:16:29 INFO Load measure computers | status=SUCCESS | time=0ms
09:16:29 INFO Compute Quality Profile status | status=SUCCESS | time=97ms
09:18:07 INFO Execute component visitors | status=SUCCESS | time=97206ms 			

09:40:50 INFO Checks executed after computation of measures | status=SUCCESS | time=1363112ms

09:40:50 INFO Compute Quality Gate measures | status=SUCCESS | time=5ms

We would like to know what kind of operations are executed on that step to see if we can find where the issue is and speed up the process by changing current settings or installation.

Enabling DEBUG level does not add any log between the “Execute component visitors” and the “Checks executed after computation of measures”. We have also tried to find the code executed on this step in the open-source sonarqube repository but we couldn’t find any related information.

We have tried to find any related release notes about this and nothing found on any 8.9.x or 9.x…

Does anyone knows what could be the reason for this long step in the compute engine? Is it related to elasticsearh, database or the compute engine itself?

Any help will be really appreciated!

Thank you!

Hey there.

This was our first release of SonarQube v8.9 LTS – and even if you can’t perform a major version upgrade, you should at least try and upgrade to the latest version (v8.9.10) which has received many fixes.

The database will be the most relevant here in any case – ensuring you have good database performance, and up-to-date indices and statistics (this can sometimes explain a performance problem that gets gradually worse over time). I hope this company has some good DBAs. :slight_smile: The live_measures table is particularly relevant here.

Hi Colin!

Thank you for your quick response! It is not so easy to perform a major version upgrade since the first re-indexing when the new version starts is taking one day (or even more) :sweat_smile:

The bottleneck is on database for sure, but we just wanted to improve performance a little bit while waiting for the database upgrade and tuning. Database is PostgreSQL 9.6 :pensive:

Just to let you know, the instance has around 1600 millions lines of code (size of all aggregated active branches and projects).

Let me ask you just one more question, if search indexes are around 6 Gb and search JVM heap is set to 2 Gb, do you think this could be the root cause for the slow step in the compute engine? We want to increase search JVM memory to at least 8 Gb but on big companies this change can take months :sweat:

Thank you very much for your support!

To be clear, when upgrading from 8.9.0 to 8.9.10, you can keep the same indices (copying the data/es folder from the old to new instance)

And, when upgrading to SonarQube v9.9 LTS, keep in mind that SonarQube now becomes progressively available instead of having to wait for the full reindexing.

No. This is all about database performance.

1 Like