You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Suggestion to consider adding a note or ideas for monitoring and handling running up on memory and disk space limitations with this setup over time.
I have been using some variation on this guide for a couple of projects.
One of them, the production and staging servers are the smallest DO droplets available.
Both systems have been very stable, production had 460 days of uptime and 418 days for staging.
It could be my config, but from what I can tell, deploying frequently using this guide can cause a lot of dangling docker images.
docker system prune can handle that, leaving most of the remaining used space taken up by (mostly unneeded) logs.
Though for memory issues, I'm not sure a lot can be done if the orchestration includes all aspects of the web application, nginx and database. I was able to reboot the machine, but going live I'll probably double the ram and start doing monitoring with datadog or similar.
Some errors I've found from disk / memory issues:
failed to register layer: Error processing tar file(exit status 1): write /usr/local/lib/python3.10/site-packages/PIL/__pycache__/ImImagePlugin.cpython-310.pyc: no space left on device
The first error shows up during the build and deploy of the deploy stage, and does not trigger a formal error in github actions. So I had to see it, almost by accident as a reason why my container was not getting updated after passing tests.
The text was updated successfully, but these errors were encountered:
Suggestion to consider adding a note or ideas for monitoring and handling running up on memory and disk space limitations with this setup over time.
I have been using some variation on this guide for a couple of projects.
One of them, the production and staging servers are the smallest DO droplets available.
Both systems have been very stable, production had 460 days of uptime and 418 days for staging.
It could be my config, but from what I can tell, deploying frequently using this guide can cause a lot of dangling docker images.
docker system prune
can handle that, leaving most of the remaining used space taken up by (mostly unneeded) logs.Though for memory issues, I'm not sure a lot can be done if the orchestration includes all aspects of the web application, nginx and database. I was able to reboot the machine, but going live I'll probably double the ram and start doing monitoring with datadog or similar.
Some errors I've found from disk / memory issues:
and
The first error shows up during the build and deploy of the deploy stage, and does not trigger a formal error in github actions. So I had to see it, almost by accident as a reason why my container was not getting updated after passing tests.
The text was updated successfully, but these errors were encountered: