[ On Thursday, June 30, 2005 at 10:48:00 (+0200), Michael Haardt wrote: ]
> Subject: Re: [exim] High Perf server
>
> On Wed, Jun 29, 2005 at 04:43:46PM -0400, Greg A. Woods wrote:
> > Don't forget that SMTP requires implementations to make commitments
> > about how reliably they can process message transactions.
>
> I wrote about a queue that does things with less disk transfers, not
> less reliably.
... and I wrote about using storage subsystems (and possibly operating
systems and filesystems) that can reliably commit files and data to safe
storage without high latency (or access contention). :-)
> Ok, so you think the queue is not the largest bottleneck?
No, but, I thought that you were saying it was, and it seems you are.
Why else would you suggest going to such extreme effort to work around
disk latency in the MTA's queuing subsystem?
> That may well
> be true in your environment.
In my high-performance environments I've chosen to use highly reliable
low-latency (and high-bandwidth) storage subsystems that make the
queuing and de-queuing almost the fastest part of e-mail transaction
processing.
> But I take it, disk transfers are not a problem for anybody else here.
Disk transfers, latency or contention, should not be a problem for
anyone who has designed their overall systems to minimize or even
eliminate that problem.
Get a pair of decent modern fibre-channel PCI host adapters (ideally
64-bit for the decently fast 64-bit PCI slots in your decently high-end
server system) that are supported by your current operating system and
then go out and buy yourself a nice shiny new Apple Xserve RAID box with
the maximum possible configuration of cache RAM (or something similar
but much more expensive if you don't like Apple). Connect each half of
the array to the separate FC HBAs which you've installed in separate PCI
buses and use one half for the queue and the other half for your mail
store (e.g. your Cyrus IMAP spool). Turn off access-time updating in
your Cyrus spool filesystem, and in your queue filesystem too if Exim
doesn't use the file access time. Don't bother with UFS soft updates or
other such features, but do choose an operating system that can be
configured to use lots of the large amounts of RAM you've stuffed your
server(s) with for the disk buffer cache. Do all the other smart tuning
things that are good to do with Exim, such as ramdisk for hints db or
whatever. If that's not fast enough then repeat with duplicate systems
(and multiple A RRs and/or multiple equal-precedence MX RRs) as
necessary until you have enough capacity to handle the required load,
using Cyrus MURDER to direct your LMTP and IMAP connections to the right
mailstore. Make sure your LDAP server(s) is(are) on separate hardware.
If you can't afford this kind of solution then you sure as heck can't
afford the _much_ more expensive programming labour that would be
necessary to go to the extremes you originally discussed, even if that
labour were to be donated. TANSTAAFL
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
