Postgresql optimize #373
Postgresql optimize #373
Conversation
README.markdown
Outdated
| @@ -94,9 +94,14 @@ precompile assets for production using: | |||
|
|
|||
| * `SECRET_KEY_BASE=none RAILS_ENV=production bundle exec rails assets:precompile` | |||
|
|
|||
| Dashboard will keep all reports in the database. If your infrastructure is big the database will eventually become very large (more than 50Gb). To periodically purge old reports and optimize the database tables it is recommended to run the following tasks periodically: | |||
|
|
|||
| * `SECRET_KEY_BASE=none RAILS_ENV=production bundle exec rails reports:prune upto=20 unit=day` | |||
There was a problem hiding this comment.
I forget, should these be rake instead of rails here and below?
There was a problem hiding this comment.
They both work. I don't know if rails intends to move some of the task off of rake in the future so it is probably best to use the rails command from now on.
README.markdown
Outdated
| @@ -94,9 +94,14 @@ precompile assets for production using: | |||
|
|
|||
| * `SECRET_KEY_BASE=none RAILS_ENV=production bundle exec rails assets:precompile` | |||
|
|
|||
| Dashboard will keep all reports in the database. If your infrastructure is big the database will eventually become very large (more than 50Gb). To periodically purge old reports and optimize the database tables it is recommended to run the following tasks periodically: | |||
There was a problem hiding this comment.
let's change 50Gb to 50GB.
let's also mention the reports:prune is recommended to be run at least once per day, and the db:raw:optimize should be at least monthly. I think that's what we were using.
There was a problem hiding this comment.
Ok, will fix that shortly
| puts "Optimizing tables, this may take a while:" | ||
| for table in ActiveRecord::Base.connection.tables.sort | ||
| puts "* #{table}" | ||
| ActiveRecord::Base.connection.execute("VACUUM FULL ANALYZE #{table}") |
There was a problem hiding this comment.
I was going to suggest maybe making this just VACUUM ANALYZE but I see it needs a FULL to reclaim disk space, and that's what mysql does in OPTIMIZE TABLE above
There was a problem hiding this comment.
Yeah the reclaiming of space is intended here.
ZeroPointEnergy
force-pushed
the
postgresql_optimize
branch
from
e26d387 to
c3b4ebc
Compare
|
I recommend we wait with merging this until we have a first release. This touches code which is not covered by tests and we should add them first and then rebase again. See #379 |
|
Ok, merging it then. |
This is the extracted and rebased postgresql optimization part form the PR #333