> On 17. Sep 2019, at 21:25, Jonathan Vanasco <[email protected]> wrote:
> - I don’t know whether it’s me, my Python DB driver (sqlanydb 😞), or the
> underlying libs: there’s stuff leaking all the time so I wouldn’t use a WSGI
> container that doesn’t do worker recycling after a configurable amount of
> requests served. Otherwise you get best case uncontrolled recycling via crash
> and worst case deadlocks.
>
> this is actually the main reason why I adopted uwsgi. a hook loads most of
> the Python we need into the shared memory before the fork, and then workers
> are recycled to our specs.
>
> how do you avoid leaks / leak-like process growth in the threaded gunicorn
> solution you adopted?
In the entrypoint:
```
--max-requests 4096 \
--max-requests-jitter 128 \
```
This means "recycle after 4096 +/- 128 requests” (The jitter is so they don’t
recycle all at once; although it’s unlikely to happen at the same time over the
whole cluster. The option is more useful when you have more than one worker.).
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/195E5F6B-44D4-42F5-B65C-809E70D833EE%40ox.cx.
