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
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
