Hi, I was running an update using ./launcher rebuild app But it stuck at 156:M 23 Jan 10:19:31.078 * 10 changes in 300 seconds. Saving... 156:M 23 Jan 10:19:31.081 * Background saving started by pid 3150 3150:C 23 Jan 10:19:31.655 * DB saved on disk 3150:C 23 Jan 10:19:31.657 * RDB: 26 MB of memory…

The update has complete after 3 hours.

Discourse occasionally runs a VACUUM on the database during migrations to make sure space is being reclaimed (see the db:migrate job in db.rake ). You can disable this behaviour by setting the vacuum_db_days site setting to 0 .

Maybe have weekly schedule trigger it if it is overdue?

That’s what autovacuum is supposed to be doing. Perhaps we just need to tweak the thresholds for that a bit?

Ahh good point. In that case, I don’t see a point in us running VACUUM ANALYZE from the app and have a PR to remove it. https://github.com/discourse/discourse/pull/4687 If we need to tweak autovacuum, we should configure it from the template in discourse_docker .

PR has been merged :slight_smile:

Update took quite long due to Vacuum

Product Support Self-hosting

tgxworld (Alan Tan) January 24, 2017, 2:47am 4

Hmm actually VACUUM ANALYZE can be run against a live DB. I think we should move it into a background process when the app is running rather than run it during a rebuild?

Topic		Replies	Views
'bundle exec rake db:migrate' taking a long time due to calendar migration Self-hosting	33	1220	December 5, 2023
Some queries that don't finish Product Support	16	1118	April 5, 2019
Update takes ~20 minutes and progress update breaks (temporarily) at step multisite:migrate Product Support dev-ops	5	331	September 18, 2024
'Updating Last Seen' and 'hijack topics timings' and 'Track Visit' is still running after 90 seconds Product Support	11	1153	October 9, 2024
2.6.0 beta 3 update failed on disk and/or memory space Self-hosting server-resources	28	3023	September 26, 2020

Update took quite long due to Vacuum

Related topics