Auteur: Andrew Johnson Date: À: Tore Anderson, exim-users CC: Sujet: Re: [exim] Performance question :-
We are investigating the accelerator, and other otions with the raid
controller.
Although we have exim compiled with SpamAssassin/Exiscan, it's barely called
or used - only for a very small subset of emails.
I didn't get chance today to look at the stats as I was investigating an
external journal (Just testing using the ram disk today, and was
experiencing wierd corruptions).
We are using ext3.
Thanks..
-Andy-
----- Original Message -----
From: "Tore Anderson" <tore@???>
To: <exim-users@???>
Cc: "Andrew Johnson" <andrew.johnson@???>
Sent: Friday, November 05, 2004 8:56 AM
Subject: 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
>