What happens during the https://url/setup

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension) 9.9.1 (previously on v9.8)
  • how is SonarQube deployed: zip, Docker, Helm. Docker
  • what are you trying to achieve. Clarification
  • what have you tried so far to achieve this. n/a

A year ago or so, we upgraded from v7.3 on a server with separate postgres DB on a different server. Then I upgraded to v7.9 and finally at v8.9. Each step of the way, I was opening the url of https://urlofserver/setup. Usually that ended up with a database action of some sort. After the application was upgraded, then I had to upgrade postgres from v12 to v13.

My question is:
What is happening when there is an action to do after one goes to https://url/setup after the application upgrade?

It was my thought that a reindex or database maintenance was happening, but after the recent upgrade from v9.8 to v9.9.1, we had extremely slow analysis times. For example an analysis used to take 12-15sec was taking over 1 hour.

Upon re-reading the release notes for v9.9.1, we performed the following:
" I thought this was included as part of the post upgrade when you go to https://url/setup, but we ran into the same issue when upgrading from docker running v9.8 to v9.9.1. However, we upgrade SQ from v9.5(?) to v9.8 and prior to that major update from v7.

I see in the v9.9.1 notes there is a section for postgres.

Additional database maintenance

Once you’ve finished a technical upgrade, you should rebuild database indexes and refresh database statistics before starting SonarQube and reanalyzing your projects.

For PostgreSQL, that means executing three operations:

  1. VACUUM FULL
  2. REINDEX DATABASE <db>
  3. ANALYZE

According to the PostgreSQL documentation:

In normal PostgreSQL operation, tuples that are deleted or obsoleted by an update are not physically removed from their table; they remain present until a VACUUM is done.

"
Our analysis are much quicker and in line than what they were prior to v9.9.1.

Please explain what is happening at https://url/setup and perhaps better communicate (ie: move it out from under Oracle heading) that 3 postgres commands need to be run upon every upgrade.

Hi,

There are a couple different questions here. Normally we try to limit it to one question per thread. Otherwise, it gets messy, fast. I’ll try to answer everything here, but reserve the right to ask you to create new threads if you have followup questions on multiple topics.

SonarQube is updating its schema for the new version. This can be things like new or dropped indices, new columns / tables &etc. That’s why the docs advise you to perform additional DB maintenance after an upgrade.

I assume most of that time was in the server-side processing? That’s the part where the database is updated with the new analysis results, so a DB in need of that post-upgrade maintenance could explain why server-side analysis report processing was slow.

I guess you mean everything got faster after the DB maintenance? Yes, that makes sense.

And additionally, we did a lot of work in the 9-series to speed up analysis, so the part that takes place on the CI side should be faster now too.

 
HTH,
Ann

At what point (in other words, what version of SQ) was it advised to perform additional DB maintenance? We are curious.

Yes performing the 3 steps for postgres appear to have resolved our issue.

Personally, I would adjust your documentation to make Postgres a Header instead of looking like a subsection of Oracle… just my 2 cents.

1 Like

Hi,

It was probably always a good idea, but (smart-assery aside) I guess you’re asking with what version the recommendation appeared in the docs. Unfortunately, I can’t tell you. I think there’s been general advice for… 4? years or so, and it’s gotten much more specific / explicit in … the last year or so?

Fair point. I’ll ping the docs folks.

 
Thx,
Ann