Re: [exim] exim using intensive hdd access

Michael da Silva Pereira wrote:
> Hi,
>
> I'm currently having a issue when receiving approx 600+ SMTP sessions
> concurrently (at least thats how many exim -MC commands are running).
> I'm running it on a HP DL380 G5 Chassis.
>
> Current setup of the server is as follows:
>
> 2 drives (software raid1) - xfs - /
> 2 drives (software raid1) - ocfs2/drbd /mailfolders (however running as
> a single node for now).
>
> There is a big bottleneck when handling multiple messages here, and I'm
> guessing IO.
>
> The Idea is to make several servers setup like this and mirror the
> "/mailfoders/" volume using ocfs2, and drbd. In an attempt to have
> complete redundancy, so If a box had to fail the next box in line would
> have all the mails and etc....
>
> Mailboxes live in a SQL database, on this box aswell. Using courier as
> the pop3a and imapa.
>
> Any suggestions on a proper redundant setup, or is this the way but
> needs some tweaks ??
>
> Thanks,
> Michale
>
>
>

I did a good deal of R&D a few years back with PowerMail and DB Mail,
thereby I'd say you may acheive decent failover (if you are redirecting
POP and IMAP clients as well as incoming smtp)...

but..

.. with few exceptions [1] any form of DB lives atop a complex structure
one or several layers removed from the on-disk fs...

AND adds a good deal of overhead of its own as well - not just I/O..

So you'll not be likely to get even close to the I/O rate of the stock
Exim queue on a 'basic' fs (read UFS, XFS, JFS, or ext(n) fs, AND NOT
ZFS, btrfs, et al).

Ditto the cost of most forms of redundancy, be it hardware/software
RAID(n), Ceph, Gfarm, Dfarm, Gluster, MooseFS ..... wotever... unless
FCAL SANS' are on your purchase order.

If you want raw speed, I'd drive multiple per-IP Exim instances with
separate configs and queues on separate spindle-sets of fast hardware
RAID1, then use an off-box mirrored SQL DB to spit out fresh static
cdb's on each change one for each of the Exim instances to use. No need
to restart, they keep running if the master SQL DB falls down, and are
*way* faster than SQL transactions.

While you are at it, Exim is IMNSHO the most flexible and easily
configured of all major MTA's - yet still capable of very heavy loads.

That said, I'd rate courier-mta faster, and postfix or sendmail faster
yet under extreme load. They don't try to do as many clever things under
one roof.

Horses for courses....

But I would perosonlly not go with a mine os bigger' server... Too many
eggs in too few baskets, as 'no fail' is too costly even on military bugets.

Splitting the load over many small cheap boxes [2] means that if/as/when
one goes down, the failover only has to carry a portion of the total
load. And if *that also* fails, you at least have only a fraction of
your clients on the phone - not 100% of 'em.

:-(

JM2CW,

Bill

[1] Some can use a raw block device directly, DB2, and/or IMS IIRC. Or
the Pick Operating System, where the DB *was* the OS, or Forth, where
the 'language' was the OS, a VM, and a VMFS storage as well, only
distinction between memory, disk, tape, audio casette... paper tape..
was speed. All were divided into 1024 Byte 'screens'.

[2] We're shifting to VIA CPU and 2.5" HDD in 'software' RAID1.
As even 'green' CPU have become faster, the limitation is the aggregate
frontside bandwidth, not just the boxen.... Plus - they don't stop
running even if the fans pack it in..

Needless to say, aggressive 'up front' spam blocking on rDNS fail does
wonders for lightening the load... Clamd and SA-spamd sleep most of the
time..

YMMV