Here some strange finding out of our SonarQube docker logs:
2024.07.03 15:56:54 INFO ce[6adffde4-fdbe-4061-8594-e349d4a61a68][o.s.c.t.s.ComputationStepExecutor] Persist live measures | insertsOrUpdates=575506 | status=SUCCESS | time=2276427ms
2024.07.03 15:56:55 INFO ce[6adffde4-fdbe-4061-8594-e349d4a61a68][o.s.c.t.s.ComputationStepExecutor] Persist duplication data | insertsOrUpdates=202 | status=SUCCESS | time=533ms
2024.07.03 15:56:55 INFO ce[6adffde4-fdbe-4061-8594-e349d4a61a68][o.s.c.t.s.ComputationStepExecutor] Persist new ad hoc Rules | status=SUCCESS | time=0ms
Hi there. We did a similar thing. We re on MsSql Server. I checked index fragmentation and it was necessay to perform defrag. I did a job to do it every week. it helps a lot but we still have sometimes big lags on UI.
After 10.6 install, still same issue.
Colleague of sczuka here, we now retestet 10.6.0 after VACUUM FULL ANALYZE, unfortunately to no avail, or maybe a tiny little bit. However it is still the case that analysis max time goes from around 15 min to 50 min and more, and in general it seems that the average analysis time for all builds and projects goes up by a factor of 3 to 10
We also retried the whole update going this time just from 10.3.0 to 10.4.1 and already encounter the problem there too. Again vacuuming did not really help.
So to sum it up a bit:
Sonarqube 10.3.0 plus postgres 16.2 or 16.3: okay
Sonarqube 10.4.1 plus postgres 16.3: unbearable slow
Sonarqube 10.6.0 plus postgres 16.2: unbearable slow
I don’t have any more advice right now. However, I am collecting a few different data points (across the community and our enterprise support channels) to provide a consolidated report of these reports to our PMs/Devs. Stay tuned.
There is one more hint we can provide. After more testing we can now say the critical slow down also happens for version 10.4.0, so the breaking point seems to be the minor jump from 10.3 to 10.4.
First analysis of a non-main branch (after the first two analyses)
This was all done on brand new SQ servers (no upgrading) against a local Postgres server. Admittedly, a fairly optimal setup.
I chose these versions to compare the last LTA, to 10.3 (where we did a lot of refactoring of the DB model), to 10.4 (new measures as noted in SONAR-21949), and 10.7 (the latest)
These are the results:
Version
1st Scan
2nd Scan
1st Scan New Non-Main Branch
9.9.7
48s
39s
28s
10.3
49s
35s
70s
10.4
67s
50s
66s
10.7
58s
56s
97s
It definitely looks like something we should investigate, and I’ve passed this on to the right folks.
I would be curious to know if your performance issues also start only at 10.3/10.4 (@morco made clear this is the case), but I understand that it’s quite some work to reproduce.
I’ll keep you posted if something comes out of it, on top of the performance improvements we already expect in 10.8 with SONAR-22870.
@Colin Do you have any idea when we can expect these performance improvements? I see the ticket you linked is flagged as “Done,” but other posts mention we shouldn’t expect 10.8 until sometime after January 2025.
At the moment, our largest project has a 3-30 hour build queue, which is frankly unacceptable.
@Colin That is some excellent news! I am also curious to hear why the degradation occurred, as well as how we’re going to make sure it doesn’t happen again!
@Colin I see that 10.8 dropped on Dec 1st but the release notes make no mention of any perf fixes. We’re going to test this out in stage anyway, but curious why it wouldn’t make it into the list
