Update took quite long due to Vacuum


(Richard Soutar) #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.

Any ideas? Thank you


(Richard Soutar) #2

The update has complete after 3 hours.


(Matt Palmer) #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.


(Alan Tan) #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?


(Sam Saffron) #5

Maybe have weekly schedule trigger it if it is overdue?


(Matt Palmer) #6

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


(Alan Tan) #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.

If we need to tweak autovacuum, we should configure it from the template in discourse_docker.


(Alan Tan) #8

PR has been merged :slight_smile:


(Alan Tan) #9