[Mailman-Users] Mailman throughput

[Ivan Fetch]

Hello,

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
> 
> try:
>    QRUNNERS.remove(('OutgoingRunner', 1))
>    QRUNNERS.append(('OutgoingRunner', 2))
> except ValueError:
>    pass
> 
> 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.

Thanks,

Ivan.























.