Slow lmtpd

[Rob Mueller]

> I had to reduce the default value of
> "lmtp_destination_concurrency_limit" in postfix to 10 (the default is
> 20), and change the value of "queue_run_delay" on some servers to avoid
> having them all run their queues at the same time, because that ends up
> causing the lmtpd process limit to be reached.

Yep, there's obviously a 2 sided limit here.

Too few lmtpds and postfix won't be able to deliver incoming mail fast 
enough, and thus the mail queue on the postfix side will build up.

Too many lmtpds and you'll IO overload the backends if you have to flush a 
large mail queue from the postfix side.

So it sounds like you had too many there, so you want to lower the 
destination concurrency limit, but don't make it so low that postfix can't 
deliver fast enough.

I guess the questions then is, in normal operating conditions when you're 
not flushing a postfix queue:
1. Is the cyrus server overloaded?
2. Does the postfix queue build up at all, or is delivering to lmtp fast 
enough?

If cyrus isn't overloaded, and postfix is delivering, and the problem only 
occurs when you're flushing a built up mail queue, then changing 
lmtp_destination_concurrency_limit to limit your lmtp connections is what 
you want.

> The Coraid people suggested me a larger array, using 14 disks to
> increase the throughput through the use of more striping elements. I can
> try this for the next servers to go into production, but changing the
> current one will be harder.

Sure that will help, the question is how much...

Rob