I’m seeing some worker time outs and strange resource spikes with a gunicorn based app, and looking into it I’m starting to wonder if there’s some alterations to the default gunicorn run command that might be helpful on render. Configuring Gunicorn for Docker
I’m going to try these and I’ll update this thread w/ results, but if anyone has done this before or has a suggestion please chime in!
Seems to be working better - I think the number of workers is lowered from 4 to 2, which is why the resting memory use is lower, but I am not getting any timeouts/crashing workers anymore
the updated command is:
gunicorn --worker-tmp-dir /dev/shm --workers=2 --threads=4 --worker-class=gthread --log-file=- <application_path>
Thank you for sharing your experiences. I’m also wondering what the optimal configuration for Gunicorn on render.com looks like.
Now that a year has passed since your last post, do you still run the same command for that setup?
I’m intrigued why render.com’s documentation for setting up Django or Flask doesn’t touch the subject of worker numbers or the heartbeat file location.
I’m pretty sure I haven’t touched that service since - not sure if the best practice has changed or not.
I think it might be owrth updating the documentation around this, yeah
Hi there,
We could certainly add some documentation for around Gunicorn worker counts considerations, I’ll make a note. However, I expect they would need to be vague.
Worker counts would depend on which plan was selected and how much resource your app uses. Every app is different, so the only surefire way to optimize things like worker counts would be to lead test the service, monitor the metrics and adjust the plan/worker count to make full use of available resources without saturating them.
Alan
Hi Alan.
Thanks for considering a documentation update. Obviously you cannot give specific advice on worker numbers or worker classes. But would you say that services on Render should set /dev/shm as a worker temp directory? DigitalOcean, for example, clearly suggest using it on their AppPlatform.
We don’t currently have any specific guidelines around where to store those files, but /dev/shm being a temporary in-memory store seems like a good place.
Alan
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
