- Previous message: Andre Nathan: "Re: Slow lmtpd"
- In reply to: John Madden: "Re: Slow lmtpd"
- Next in thread: Andre Nathan: "Re: Slow lmtpd"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Andre Nathan (no email)
Date: Wed Mar 07 2007 - 07:40:38 EST
On Tue, 2007-03-06 at 08:57 -0500, John Madden wrote:
> 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. :)
Yep, TCP. I should have mentioned that.
> 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!
Hmm, I never thought of having two "layers" of MTAs like this. I'll add
it to the list of things to try.
> 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.
I could try that for later systems (changing the raid config on the
current one is not possible without moving everything to another
machine). The thing about this solution that I don't like is
that /var/lib/imap is only ~300MB here, so it would waste a lot of disk
space. But then, maybe that's a small price I'd have to pay.
Thanks,
Andre
---- 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
|
|
|