Update took quite long due to Vacuum

Product Support Self-hosting

AI-generated summary

A user, rsoutar, experienced a delayed update using ./launcher rebuild app due to a lengthy VACUUM process. The update took three hours to complete rsoutar. mpalmer explained that Discourse occasionally runs VACUUM on the database during migrations to reclaim space, and this behavior can be disabled by setting vacuum_db_days to 0. However, tgxworld suggested moving the VACUUM process to a background task, and sam proposed scheduling it weekly if overdue. mpalmer pointed out that autovacuum should handle this, and tgxworld ultimately created a PR to remove the VACUUM process, which was later merged tgxworld.

1

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 used by copy-on-write
156:M 23 Jan 10:19:31.714 * Background saving terminated with success
2017-01-23 11:23:52 UTC [3137-57] discourse@discourse WARNING:  skipping "sql_languages" --- only table or database owner can vacuum it
2017-01-23 11:23:52 UTC [3137-58] discourse@discourse WARNING:  skipping "sql_packages" --- only table or database owner can vacuum it
2017-01-23 11:23:52 UTC [3137-59] discourse@discourse WARNING:  skipping "sql_parts" --- only table or database owner can vacuum it
2017-01-23 11:23:52 UTC [3137-60] discourse@discourse WARNING:  skipping "sql_sizing" --- only table or database owner can vacuum it
2017-01-23 11:23:52 UTC [3137-61] discourse@discourse WARNING:  skipping "sql_sizing_profiles" --- only table or database owner can vacuum it
WARNING:  skipping "sql_languages" --- only table or database owner can vacuum it
WARNING:  skipping "sql_packages" --- only table or database owner can vacuum it
WARNING:  skipping "sql_parts" --- only table or database owner can vacuum it
WARNING:  skipping "sql_sizing" --- only table or database owner can vacuum it
WARNING:  skipping "sql_sizing_profiles" --- only table or database owner can vacuum it

Using htop I saw that it running a VACUUM for an hour or so.

fe3409acdc.png1302×666 26.2 KB

Any ideas? Thank you

2

The update has complete after 3 hours.

3

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.

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?

5

Maybe have weekly schedule trigger it if it is overdue?

6

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

7

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.

8

PR has been merged :slight_smile: