-
-
Notifications
You must be signed in to change notification settings - Fork 918
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Database vacuuming either not running or unoptimized. #1128
Comments
I'm guessing we touch autovacuum_vacuum_cost_limit and or autovacuum_vacuum_cost_delay in https://github.com/OpenDroneMap/WebODM/blob/master/db/Dockerfile maybe around line 58. |
I didn't even know this was a thing (why doesn't postgres do this automatically?), so I'll go with whatever suggestion. |
It's that old addage: configuration over convention. Wait... .
If this is the right place, I'll take a stab at a pull request. |
I'm going to defer to you, Stephen. I don't understand PGSQL enough to do anything other than guess. My familiarity is just with GeoPackage/SQLite on smaller deployments than we'd see ODM scale to. |
Hi, I've just spent a lot of time looking in to this issue and what causes it, it's hard to pin down, I've dug into the internals of postgresql a lot more than I wanted to and I have heaps of debugging info and further details I can share, but here are my conclusions so far:
Possible actions if I'm coming to the right conclusions:
|
If I understand your analysis, do we need to be performing a transaction for console output as it is produced? This explains what I see in locked logs on long running processes all the time. I see the logs continue in NodeODM but no updates in WebODM. I don't know why we would want to wrap those updates in a transaction in WebODM until the log is complete (either a processing failure or success). |
Each console /status update is still a single transaction, they just take a little longer than they should sometimes when the log gets big and there are many happening at once. They are quite frequent and involve changing a very large text field. The autovacuum on the other hand is a single long transaction that seems to get stuck/frozen and need killing in some situations. I could be wrong, but it seems like it's actually just a pattern that doesn't work well with the default autovacuum settings of postgresql, that is: updating a large field text field frequently in this way, especially when there are multiple jobs running with very long log outputs. |
I think this page explains most of the issue: https://www.postgresql.org/docs/9.0/routine-vacuuming.html |
There may be aggressive enough tweaks to autovacuum, as long as they're enough to prevent it getting into this territory, which is the state I keep finding our db:
I've still got a known problem job I can run so will try some autovacuum settings changes and let it run overnight. |
I've tried some very aggressive autovacuum settings from this post as a test https://dba.stackexchange.com/a/21649
This seems to be working to keep the database size trimmed for now with a single job running, will see how it goes after running longer and adding some more jobs. For our use case we'll often have many users and jobs running on the same WebODM instance and this could easily raise it's head again if we don't fix the underlying cause. |
A PR for the autovac settings would be fantastic. Thanks for sharing your findings! |
Taken from here https://dba.stackexchange.com/a/21649 to fix OpenDroneMap#1128 This could be overkill, but has fixed the issue in my testing, could impact performance for concurrent users of the database.
How did you install WebODM (docker, installer, etc.)?
Seriously dockerized here.
What's your browser and operating system? (Copy/paste the output of https://www.whatismybrowser.com/)
Not relevant.
What is the problem?
Autovacuum is either not set or untuned in WebODM
How can we reproduce this? (What steps trigger the problem? What parameters are you using for processing? Include screenshots. If you are having issues processing a dataset, you must include a copy of your dataset uploaded on Dropbox, Google Drive or https://dronedb.app)
See this: https://community.opendronemap.org/t/what-is-eating-up-my-hard-disk-part-dieux-pssst-spoiler-its-the-database-not-being-vacuumed/10330
The text was updated successfully, but these errors were encountered: