# Background task time different with same project but different instances **URL:** \ **Category:** SonarQube Server / Community Build\ **Tags:** java\ **Created:** [May 21, 2024, 6:30am UTC](https://community.sonarsource.com/t/background-task-time-different-with-same-project-but-different-instances/115659 "2024-05-21T06:30:08Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Ievgen\_Provorov](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/ievgen_provorov/32/57905_2.png) [@Ievgen\_Provorov](https://community.sonarsource.com/u/Ievgen_Provorov)\ **Post date:** [May 21, 2024, 6:30am UTC](https://community.sonarsource.com/t/background-task-time-different-with-same-project-but-different-instances/115659/1 "2024-05-21T06:30:08Z")
- Sonarqube 10.2.1.78527\* - Deployed into OpenShift cluster with helm chart 10.2.1\* - Goal - decrease background task execution time\* - what have you tried so far to achieve this - update sonarqube, add more resources to the instance\* Hello. I have two equal instances of sonarqube deployed into 2 same cluster. I’ve imported one project into both instances, and integrated scan task into cicd pipeline. One test branch has approx 1 commit per day and during scan background task take approx 1-2 minute it scanned by instance A, another branch has 5-10 commits per day but during scan background task takes more than 10 minutes that leads to the error “Quality Gate status timeout”. Of course I can fix it with changing timeout but this will extend pipeline execution time Plugin that used `sonar-maven-plugin:3.11.0.3922` What may affect background task execution time and how can I reduce it? Project has about 400k lines of code ---
**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\ **Post date:** [May 22, 2024, 7:17am UTC](https://community.sonarsource.com/t/background-task-time-different-with-same-project-but-different-instances/115659/2 "2024-05-22T07:17:09Z")
Hey there. The most likely culprits for compute engine performance are latency between the database and SonarQube, database performance (CPU / Memory / Disk), and regular database maintenance. What database are you using (Postgres, SQL Server, Oracle) and where is it located relative to your SonarQube instance? ---
**Author:** ![Ievgen\_Provorov](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/ievgen_provorov/32/57905_2.png) [@Ievgen\_Provorov](https://community.sonarsource.com/u/Ievgen_Provorov)\ **Post date:** [May 23, 2024, 12:33pm UTC](https://community.sonarsource.com/t/background-task-time-different-with-same-project-but-different-instances/115659/3 "2024-05-23T12:33:52Z")
It’s postgres, deployed in the same cluster and same namespace, I used helm chart for the deployment so it manages both instances, also as I see that cpu and memory consumption is minimal, like 200milicores vs 1G and requests are 1CPU vs 2Gb. About database maintenance, did I miss something, I thought it provided by ttl or something like this, and during updates it’s reindexing, maybe I need some extra things to do? ---
**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\ **Post date:** [May 27, 2024, 2:09pm UTC](https://community.sonarsource.com/t/background-task-time-different-with-same-project-but-different-instances/115659/4 "2024-05-27T14:09:54Z")
I’m not really sure what you’re referring to by `ttl`. The maintenance I’m referring to is essentially what’s outlined in this post: > [@SonarQube becomes slow after PostgreSQL upgrade](https://community.sonarsource.com/t/sonarqube-becomes-slow-after-postgresql-upgrade/37925): > > 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… ---
**Author:** ![Ievgen\_Provorov](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/ievgen_provorov/32/57905_2.png) [@Ievgen\_Provorov](https://community.sonarsource.com/u/Ievgen_Provorov)\ **Post date:** [May 27, 2024, 2:55pm UTC](https://community.sonarsource.com/t/background-task-time-different-with-same-project-but-different-instances/115659/5 "2024-05-27T14:55:35Z")
Thank you very much for your answer. Actually I didn’t try this before. Under TTL I meant only housekeeping settings in administration panel. But today I’ve made something similar according this [https://docs.sonarsource.com/sonarqube/latest/setup-and-upgrade/upgrade-the-server/post-upgrade-steps/#clean-up-postgresql](https://docs.sonarsource.com/sonarqube/latest/setup-and-upgrade/upgrade-the-server/post-upgrade-steps/#clean-up-postgresql) Hope it will help. I thought such tasks executed automatically during updates, but as I understood not ---
**Author:** ![Ievgen\_Provorov](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/ievgen_provorov/32/57905_2.png) [@Ievgen\_Provorov](https://community.sonarsource.com/u/Ievgen_Provorov)\ **Post date:** [May 29, 2024, 5:26am UTC](https://community.sonarsource.com/t/background-task-time-different-with-same-project-but-different-instances/115659/6 "2024-05-29T05:26:50Z")
Finally my issue has been resolved with es reindexing. I’ve deleted /data/es8 folder and restarted contained. Background task time become normal. Hope won’t need to do it often 🙂