> 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. Are you connecting to lmtpd over TCP or something? I haven't seen this behavior with Postfix and a UNIX socket, at least. But still, I'd rather have Postfix defer the connection than have huge IO wait queues. ...If nothing else, think about what that's doing to your IMAP clients. :) > 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. Ah, it sounds here like you're connecting multiple SMTP frontends to a single lmtpd backend? Sorry if I missed that earlier. FWIW, I'd stick postfix on this box to handle the incoming mail and do all that over SMTP, then deliver over LMTP to Cyrus locally and over a unix socket. SMTP ought to prove more reliable than LMTP over a network, IMO. This has the added benefit of only having to tweak one Postfix install for its delivery to lmtpd! > There is only one RAID-10 array using 8 disks. The whole system is > installed on this array, although directories like /var/lib/imap > and /var/spool/imap are mounted on different LVM volumes. How difficult would it be to change this? It's RAID-10, but it boils down to one spindle handling all of your I/O. > 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. I think you'd be better off with smaller disk sets for different I/O patterns. Like a 2-disk RAID-1 for /var/lib/imap and the rest striped for /var/spool/imap, etc. Either way, you want to separate not just on LVM, but on the physical spindles doing the work. John -- John Madden Sr. UNIX Systems Engineer Ivy Tech Community College of Indiana jmadden@xxxxxxxxxxx ---- 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