[Mailman-Users] Mailman throughput
ifetch at du.edu
Mon Aug 15 01:25:52 CEST 2011
On Aug 14, 2011, at 4:15 PM, Mark Sapiro wrote:
> No. Threaded delivery in SMTPDirect.py was an experimental feature in
> Mailman 2.0. It was never implemented for Mailman 2.1 although the
> setting and its documentation were not removed from Defaults.py. Setting
> this in mm_cfg.py has no effect. Any difference would be due to random
> variation or other factors.
> What I meant was to put something like
> QRUNNERS.remove(('OutgoingRunner', 1))
> QRUNNERS.append(('OutgoingRunner', 2))
> except ValueError:
> in mm_cfg.py and restart Mailman. The above will cause Mailman to start
> two copies of OutgoingRunner with each processing half of the hashed
> queue space. See the
> # Qrunner defaults
> section in Defaults.py for more info.
Ok, I did this, and verified that more outgoing processes were started (in the qrunnenr log, and with ps). Testing 5000 messages to a list with 25 recipients took:
8 & 1/2 minutes with 1 outgoing slice
5 & 1/2 minutes with 2 slices
exactly 5 minutes with 4 slices.
I noticed that the incoming qrunner was using 10% CPU (according to the pcpu column of ps) even after qfiles/in was empty, and after all 5000 messages were processed. I wonder what the incoming runner is doing - any ideas there?
> Just FYI, bounce processing never sees the retries until such time as
> Mailman's retry processing gives up on the delivery (default after 5 days).
OK, this just means that a message which is tempfailing will have to get retried for 5 days, before normal bounce processing rules can (potentially) act on it. I suspect a lot of these addresses are our own accounts which are tempfailing because they are disabled, in some sort of transition, or have broken LDAP records - I will look at smtp-failure some more.
More information about the Mailman-Users