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 .

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?

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) 2017 年 2 月 20 日午前 1:09 8

PR has been merged

トピック		返信	表示
'bundle exec rake db:migrate' taking a long time due to calendar migration Self-hosting	33	1220	2023 年 12 月 5 日
Some queries that don't finish Product Support	16	1121	2019 年 4 月 5 日
Update takes ~20 minutes and progress update breaks (temporarily) at step multisite:migrate Product Support dev-ops	5	331	2024 年 9 月 18 日
'Updating Last Seen' and 'hijack topics timings' and 'Track Visit' is still running after 90 seconds Product Support	11	1153	2024 年 10 月 9 日
2.6.0 beta 3 update failed on disk and/or memory space Self-hosting server-resources	28	3025	2020 年 9 月 26 日

Update took quite long due to Vacuum

関連トピック