[PurgeCeActivities] Delete the Compute Engine tasks - takes too long to finish

Hello,

We are running into a problem of the Compute Engine not being able to start, since it blocks infinitely on the task [o.s.c.q.PurgeCeActivities] Delete the Compute Engine tasks created before Sun Jul 29 11:57:17 CEST 2018

Here is our understanding what happened:

  • our Sonar instance hasn’t been restarted for quite a while
  • yesterday we had to restart (alignment with new LDAP configuration)
  • when starting up, the Compute Engine apparently tries to purge the old tasks, and since Sonar hasn’t been restarted, there should have been accumulated quite a number of those tasks to purge.
  • the database is working relentlessly to perform the query, blocking all the other activities, and in particular blocking Compute Engine to start

Here is the query that is being executed on the DB side:
delete from ce_scanner_context where task_uuid in ( … very long list of ids like @Pxxx … )

As has been said above, this query takes very long to execute, and during this time the Sonar Qube is unusable, since Compute Engine is not able to start.

Could you please provide us with any help with this issue?

The answers to the following questions will be highly appreciated:

  • is there a way to reduce the number of id’s in the “in” clause? Probably, we could change a parameter, increasing the period of time of purge from half-year to longer?
  • should we restart Sonar Qube regularly in order to prevent these kind of problems in the future?
  • is there a cron job to start to purge regularly the DB, reducing the risk of accumulating of an unnecessary data.

Any help, or any suggestions will be highly appreciated!

Sincerely,
Emzar

Hello,

Could you provide the version of SonarQube and the database you are running?

Cheers,

Yes, with pleasure! sorry for not stating that in the beginning!

The version of Sonar we are running is 6.7.1 (build 35068)

The database is the Microsoft SQL Server 2016

Hello,

For the record, SonarQube can actually be used. This only prevents the processing of background tasks (which, I agree, is quite a limitation).

Answering each question in order:

  • no, the number of id is “all older than 4 weeks” and it is not configurable
  • for sure this would have the effect you’re looking for with 1st question
  • there is none

I’m curious:

  • has your SQ instance been running for a such a long time to have that many IDs to delete?
  • did you manage to start? how long did it take in the end?

Depending on how many IDs should be deleted, either it’s really a large number and/or you may have some issue with your database instance regarding mass deletion in this table (it contains BLOB data, but it shouldn’t be so large, if it may help investigating). Unfortunately, I won’t be able to help on MsSQL.

Anyway, I’ve created a ticket to improve this situation: SONAR-11675.

Cheers,

Hello, thanks a lot for your answers!
And the ticket!

To answer your questions:

  • has your SQ instance been running for a such a long time
    well, i guess, yes, at least a year, or may be more…
  • actually our server ended up finishing the job of deleting the old data, and eventually could start, as expected. It took it around 2 hours to finish the job

Probably we should restart it more often, once a month, or so…

Thanks again!