Project

General

Profile

Actions

tickets #101842

closed

mailman3 - nginx memory usage?

Added by pjessen about 3 years ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Mailing lists
Target version:
-
Start date:
2021-11-02
Due date:
% Done:

50%

Estimated time:

Description

I was looking at 'uwsgi' being frequently killed by the oom killer, and I also happened notice that our 6-7 nginx processes take up about 800-900Mb, each.
I'm guessing this is due to mails.redirmap, with its 3million entries ?
I think this could be improved on by using a program redirmap, like on apache - a simple 'grep' for uri takes about 200ms.


Related issues 2 (0 open2 closed)

Related to openSUSE admin - tickets #102203: mailman3 - uwsgi / gunicorn memory leak?Resolvedcrameleon2021-11-10

Actions
Related to openSUSE admin - tickets #113111: lists.opensuse.org - webserver backand timeouts - nginx 504 gateway timeoutResolvedcrameleon2022-06-28

Actions
Actions #1

Updated by pjessen about 3 years ago

  • Private changed from Yes to No

if we redirect every access to the old archives, via a simple regex, to a script that just greps mails.redirmap ?

Actions #2

Updated by lrupp over 2 years ago

  • Category set to Mailing lists
Actions #3

Updated by pjessen over 2 years ago

  • Related to tickets #102203: mailman3 - uwsgi / gunicorn memory leak? added
Actions #4

Updated by pjessen over 2 years ago

  • Related to tickets #113111: lists.opensuse.org - webserver backand timeouts - nginx 504 gateway timeout added
Actions #5

Updated by pjessen over 1 year ago

I have spent a couple of days writing a small proxy daemon for rewriting those archive urls.

Pseudo-code:

read in rewritemap  (/etc/nginc/mails.rewritemap)
hash every URL, then qsort.
while 1
read proxy requests from nginx
parse and hash url
do binary lookup
return 301 if found else 404
endwhile

This is currently running on mailman3, un-salted. The source code is in /home/pjessen/archive_rewriter
At runtime, it takes up about 300Mb which is less than 1/3 of what nginx uses today. Due to the binary search, I expect it will be also be significantly faster than nginx.

Actions #6

Updated by pjessen over 1 year ago

pjessen wrote:

Due to the binary search, I expect it will be also be significantly faster than nginx.

Judging by some rough elapse time measurements, it looks like it'll easily do 10'000 requests/second, single-threaded. That ought to be sufficient 😊

Actions #7

Updated by pjessen over 1 year ago

At runtime, it takes up about 300Mb which is less than 1/3 of what nginx uses today

After running for a few hours, the memory footprint shrinks to about 160-170Mb. It does of course depend on actual activity, but it's not bad.

Actions #8

Updated by pjessen over 1 year ago

  • Assignee set to pjessen
  • % Done changed from 0 to 50

after I fixed #102203, the memory situation on mailman3 has improved radically. Last night, one (1!) run-away gunicorn process was oom killed, but that was the first time in more than ten days. Currently, mailman3 has 8Gb free memory.
Tbh, I'm not sure if the huge nginx rewriting maps were a genuine problem, but at least nginx is looking a lot "slimmer" now.

Next step, saltifying ...

Actions #9

Updated by crameleon 5 months ago

  • Status changed from New to Resolved

Uwsi seems no longer used. Gunicorn out of memory situations have been worked around using systemd memory capping. Nginx seems to no longer be as loaded now with archrwr.

Actions

Also available in: Atom PDF