Re: Slow lmtpd

From: John Madden (no email)
Date: Tue Mar 06 2007 - 08:57:31 EST

  • Next message: Jerome Nenert: "Re: single instance store and replication"

    > 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
    ----
    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
    

  • Next message: Jerome Nenert: "Re: single instance store and replication"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD