Quality analysis becomes very slow on the master branch after upgrading to 2025.1

[git-hulk (hulk)]

Must-share information (formatted with Markdown):

• which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension)

SonarQube Server / Community Build

v25.1.0.102122

• how is SonarQube deployed: zip, Docker, Helm

zip

• what are you trying to achieve

The quality analysis becomes very slow(more than 4 minutes) after upgrading to 25.1 and it only happens on the BRANCH type report when merging into the master. We found most of our time were spent on the following steps:

• “Build tree of components” about 125s
• “Build list of dependencies” about 125s

And everything goes well when the report type is the Pull Request.

Do you guys have any idea?

2025.02.20 11:52:07 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Generate analysis UUID | status=SUCCESS | time=0ms
2025.02.20 11:52:07 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Load analysis metadata | status=SUCCESS | time=5ms
2025.02.20 11:52:07 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Initialize | status=SUCCESS | time=0ms
**2025.02.20 11:54:13 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Build tree of components | components=1074 | status=SUCCESS | time=125757ms**
2025.02.20 11:54:13 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Validate project | status=SUCCESS | time=17ms
2025.02.20 11:54:14 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Load quality profiles | status=SUCCESS | time=904ms
2025.02.20 11:54:14 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] This step pushes telemetry data from the Sonar analyzers to Telemetry V2 server in case telemetry is enabled. | status=SUCCESS | time=0ms
**2025.02.20 11:56:19 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Build list of dependencies | dependencies=0 | status=SUCCESS | time=125486ms**
2025.02.20 11:56:19 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Checks executed before computation of measures | status=SUCCESS | time=0ms
2025.02.20 11:56:19 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Generate SQ Upgrade analysis events | status=SUCCESS | time=14ms
2025.02.20 11:56:19 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Load file hashes and statuses | status=SUCCESS | time=73ms
2025.02.20 11:56:19 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Load Quality gate | status=SUCCESS | time=7ms
2025.02.20 11:56:19 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Load new code period | status=SUCCESS | time=6ms
2025.02.20 11:56:19 INFO  ce[07c58164-7902-4467-b687-de921e0c3dab][o.s.c.t.s.ComputationStepExecutor] Load prioritized rules | status=SUCCESS | time=5ms

[Colin]

Hey there.

What database server (Postgres, Oracle, Microsoft SQL Server) is backing your SonarQube instance?

[git-hulk (hulk)]

Hi Colin,

Thanks for your reply.

We’re using Postgre as our back storage.

[Colin]

Thanks! This is the first thing I always suggest:

SonarQube becomes slow after PostgreSQL upgrade

Hello SonarQube Operators! It’s common that after performing an upgrade of PostgreSQL, a SonarQube instance connected to a PostgreSQL database can become painfully slow. Thankfully, we know how the issue can usually be addressed (it works almost every time!): by executing the following command against your Postgres database. VACUUM FULL ANALYZE For a PostgreSQL database, a VACUUM FULL command reclaims unused storage, while the ANALYZE command updates statistics used by the planner to determi…

[git-hulk (hulk)]

Thank you! I will give it a shot.

[Colin]

Hey @Alan_Zhang

I’ve moved your post here where you colleague reported the same issue.

Has your team tried what I recommended above?

SonarQube becomes slow after PostgreSQL upgrade

Hello SonarQube Operators! It’s common that after performing an upgrade of PostgreSQL, a SonarQube instance connected to a PostgreSQL database can become painfully slow. Thankfully, we know how the issue can usually be addressed (it works almost every time!): by executing the following command against your Postgres database. VACUUM FULL ANALYZE For a PostgreSQL database, a VACUUM FULL command reclaims unused storage, while the ANALYZE command updates statistics used by the planner to determi…

[Alan_Zhang]

Yes，But not work.

[Colin]

Hey again.

I have a couple more questions.

• Is the analysis slow only on the first analysis of a branch analysis after upgrade, or all subsequent analyses?
• Do you have any 3rd party plugins installed on your SonarQube server?
• Does this affect all projects, or only one?