Slow lmtpd

[lst_hoe01 at kwsoft.de]

Zitat von Andre Nathan <andre at digirati.com.br>:

> On Tue, 2007-03-06 at 09:13 +1100, Rob Mueller wrote:
>> I've never seen over 100%, and it doesn't seem to make sense, so I'm
>> guessing it's a bogus value.
>
> Yeah, I talked to the Coraid guys and they told me iostat reports
> incorrect values for AoE.
>
>> > avg-cpu:  %user   %nice %system %iowait   %idle
>> >           2.53    0.00    5.26   89.98    2.23
>>
>> However this shows that the system is mainly waiting on IO as we expected.
>
> Yep, although I'd say it's a bit more than expected...
>
>> Really you never want that many lmtpd processes, if they're all in use, it's
>> clear you've got an IO problem. Limiting it to 10 or so is probably a
>> reasonable number to avoid complete IO saturation and IO sevice delays.
>
> The problem in limiting them to a lower value is that once the MTAs
> start running their queues, their connections will start being refused,
> since all lmtpd's will be in use, and the messages will go back to the
> queue.

You should always limit your MTA(s) (Postfix) LMTP clients to match the 
max number at your LMTP Server (Cyrus). Be sure to use a separate 
transport for lmtp and use the lmtp_connection_cache and maybe raise 
the max_use value. With this even small numbers of LMTP clients (<5) 
will be able to saturate your Cyrus I/O so no need to get in trouble 
with many hundreds LMTPs waiting for I/O slots.
I would start with 2 LMTP client connections per MTA and see what 
happens. As said if you don't have long running sieve scripts this 
should be enough to get near the max transferrate your Cyrus can handle.

Regards

Andreas