On 2025-01-15 10:04:54, Antoine Beaupré wrote: [...]
> This thread on the upstream mailman mailing list mentions people don't > have this kind of problem with gunicorn: > > https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/thread/QCTB7Y6W7I7GDRCIJKFNEVQB7DSNC4WG/ > > So I'm tempted to reassign this bug report to the uwsgi package, > although perhaps the mailman3-web package should work on switching to > the different process manager than uwsgi, at least as an option, to > resolve that issue. > > We'll be experimenting with gunicorn and report back here. So we've done that, and here's our report back. It's been a little over 24 hours and we can already say that we still get OOMs under gunicorn. The interesting thing is that it's a different process showing the OOM condition: instead of it being gunicorn itself (which you'd expect if it was designed like uwsgi or apache2-mod-wsgi), it's Python itself eating all the memory. See this comment: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41957#note_3151902 Directly link to the per-process memory graph: https://gitlab.torproject.org/-/project/441/uploads/c8ebf60612c426688e651853f251edd5/mem3.png So my theory, at this moment, is that the assumption that the problem is related to the process manager (uwsgi or apache or gunicorn) is incorrect; this is actually and truly a memory management issue inside the Python process running mailman3-web. This bug report would, therefore, seem to be filed at the right place. The question at this point is: how do we profile this any further? Any advice? run a memory profiler like austin? a. -- The destiny of Earthseed is to take root among the stars. - Octavia Butler
