On 2025-01-23 16:20:07, Antoine Beaupré wrote: [...]
> 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? We found a fix. First, we tried austin, but it was filling up our logs more than anything. Then lavamind found the trick: turns out the mbox export slurps the entire archive in memory before compression. https://gitlab.com/mailman/hyperkitty/-/issues/385 oops. so this is a bug in hyperkitty, and a pretty big one, IMHO. this is denial-of-service security level stuff, but it's being treated as a feature request upstream. the workaround is to set `HYPERKITTY_MBOX_EXPORT = False` perhaps we could ship such a configuration in debian by default? incident closed on our end, thanks everyone here for the help! a. -- Le péché est né avant la vertu, comme le moteur avant le frein. - Jean-Paul Sartre
