logo

pleroma

My custom branche(s) on git.pleroma.social/pleroma/pleroma
commit: 114e7b764ed5ae03211cca40e7b19f33292b3d1c
parent: 292031f6dd809accbcb3a5ba59d0100d807c5d72
Author: lain <lain@soykaf.club>
Date:   Fri, 21 Feb 2020 19:34:45 +0000

Merge branch 'patch-1' into 'develop'

added why doing a vacuum after restoring a backup is so important

See merge request pleroma/pleroma!2230

Diffstat:

Mdocs/administration/backup.md4+++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/docs/administration/backup.md b/docs/administration/backup.md @@ -18,7 +18,9 @@ 6. Run `sudo -Hu postgres pg_restore -d <pleroma_db> -v -1 </path/to/backup_location/pleroma.pgdump>` 7. If you installed a newer Pleroma version, you should run `mix ecto.migrate`[^1]. This task performs database migrations, if there were any. 8. Restart the Pleroma service. - +9. After you've restarted Pleroma, you will notice that postgres will take up more cpu resources than usual. A lot in fact. To fix this you must do a VACUUM ANLAYZE. This can also be done while the instance is still running like so: + $ sudo -u postgres psql pleroma_database_name + pleroma=# VACUUM ANALYZE; [^1]: Prefix with `MIX_ENV=prod` to run it using the production config file. ## Remove