Yes, Postfix is also running, but this system currently has a trivially
small configuration (single domain, single digit number of lists). When
the CPU is kept ~100% busy for (maybe once as few as a) dozen minutes to
(usually 20 minutes, but rarely) an hour [1] during mailman start,
essentially all of the CPU time is being consumed by the dozen or so
mailman runner processes, so I do not think Postfix alias processing has
much if anything to do with these delays.
[1] wall clock time; as an arbitrary indicator of how many cycles VMWare is giving to this server, here is what 7-zip observes:
x@localhost:~$ 7za b
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,1 CPU Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz (406F0),ASM,AES-NI)
Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz (406F0) CPU Freq: - - - - - - - - -
RAM size: 425 MB, # CPU hardware threads: 1 RAM usage: 219 MB, # Benchmark threads: 1
Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS
22: 2909 99 2861 2831 | 29117 99 2502 2486 23: 2370 88 2741 2415 | 28833 99 2512 2496 24: 1937 79 2622 2083 | 27937 98 2501 2453 ---------------------------------- | ------------------------------ Avr: 89 2741 2443 | 99 2505 2478 Tot: 94 2623 2461 x@localhost:~$
On 6/8/23 10:14, Stephen J. Turnbull wrote:
Nelson Strother writes:
I did not intend to imply that
mailman start(predictably) consumes more time thanmailman restart. Both are lengthy and variable;You did say something about "30min" I believe. I don't understand why it would take anywhere near that long. For example, I'm working with a site with ~20,000 lists, and it only takes a few seconds.
Oh ... wait ... are you using Postfix as the MTA? The supplied Postfix MTA interface rebuilds the list aliases database on every (re)start, and that's an O(#lists^2) process the way Mailman does it. Postfix doesn't actually use the file to route mail, it always goes to lmtp:127.0.01 or something like that. So I configured Postfix to probe for existence of the list in Mailman's database.
I think Postfix has plugins for all Mailman-supported databases (PostgreSQL, MySQL/MariaDB, SQLite3). I can provide the changes needed for this for PostgreSQL right away, if you're a MySQL site I can give you the PostgreSQL config to give you the idea, but I may be sslow if you want advice about the MySQL config. It's pretty straightforward, though.
I do not yet understand how to make use of these clues, but at least one can see an epitaph from each deceased process.
I don't understand them either. The only thing I can think of is that a runner may try to access Mailman core, timeout, and crash during the long startup.
At least the MTA reconfig would make the restart cycle a lot less painful. Note: this is NOT a Mailman-supported config (or even contrib quality) yet, but I'm pretty confident of the theory and it is working well in QA testing.
Regarding the "alpha" status of the config, one Mailman 3 instance can support multiple domains, but the Postfix docs say not to hit the database for the "domain exists" check. If you aren't going to add additional Mailman domains, then this doesn't matter (the domain list file produced by the stock Mailman postfix config will work), but if you do add or remove domains, you either need to configure Postfix to hit the database for the "domain exists" check too contrary to Postfix's advice, or you'd need to manage the domain list file by hand.
In any case, you could use this config for debugging, and go back to the tried and true aliases file approach for production. And as I indicated I'm somewhat available on a best-effort basis for trouble-shooting.
Mailman-users mailing list --mailman-users@mailman3.org To unsubscribe send an email tomailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at:https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent tojustfixit@marilynstrother.com