Re: [exim] Performance question :-

* Andrew Johnson

> I'm having a little trouble with performance on one of our email
> servers :-
>
> Spec :-
> HP DL380 Dual 2.4Ghz Processor
> 4GB Ram
> 3*36GB 15K RPM Disks in a Raid 5 (64MB read cache)
> RedHat Enterprise 3 Linux
> Exim 4.41 With exiscan & SpamAsassin compiled in.
[...]
> Obviously the system is IO-Bound, I was wondering if there was any
> advice on how I could reduce this delay.

Any MTA does a -lot- of fsyncs, which is a real performance killer.
RAID-5 just makes things worse too. If you're looking to improve fsync
performance the best way would be to purchase a battery-driven write-
back cache (dedicate all of it to write cache, the OS will do read
caching anyway). IIRC HP calls these addons "Array Accelerator" (at
least for the DL360es). Alternatively, if you're using ext3, you could
try mounting the filesystem with the data=journal option. That'll cut
your write bandwith in half, but if you're not using more than half of
your current bandwith anyway this can improve latency significantly, as
the fsync's will return after having committed the writes to the
journal, which alleviates the need for expensive seeks - you're just
appending. Remember to increase the size of the journal, though.
noatime and nodiratime are also useful mount options for mail spools,
as they eliminate a lot of writes generated by useless metadata
updates.

However, only two email a second sounds ridiculously little in any
case. Are you absolutely sure that I/O performance is the problem
(check with iostat -x 1/vmstat 1)? Given that you're running Exiscan
I'm inclined to think otherwise. SpamAssassin can use very much time
per message if a DNS blacklist or another remote check has to time out.
Check the syslog, spamd will note how much time it uses per message.

I'd try using "smtp_acl_data = accept" and see if that fixes the
problem. If it does, the problem is somewhere in your content
filtering engines.

--
Tore Anderson