Project

General

Profile

Actions

tickets #101842

open

mailman3 - nginx memory usage?

Added by pjessen over 2 years ago. Updated about 1 year ago.

Status:
New
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 (2 open0 closed)

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

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

Actions
Actions #1

Updated by pjessen over 2 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 about 2 years ago

  • Category set to Mailing lists
Actions #3

Updated by pjessen almost 2 years ago

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

Updated by pjessen almost 2 years ago

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

Updated by pjessen about 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 about 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 about 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 about 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

Also available in: Atom PDF