Re: [Exim] High Load

Top Page
Delete this message
Reply to this message
Author: Nigel Metheringham
Date:  
To: Felix Havemann
CC: exim-users
Subject: Re: [Exim] High Load
On Wed, 2003-04-09 at 13:40, Felix Havemann wrote:
> The SunFire V100 uses an IDE-Disk and the filesystem is xfs. Changing
> things here is the last thing I want to do. This would mean to buy new
> hardware. An option could be to use a RAM-disk, as you mentioned.


If this is effectively a box to push out mass mailings then you could
use a RAM disk for the queue. If it all went wrong then you would
regenerate the injected message. Alternatively - and maybe just as good
- switch off fsync (maybe that can be done in kernel or fs, otherwise
hack the sources). Normal mail operations require that the message is
committed to stable storage before the MTA can count it as accepted
(hence the need for fsync and therefore synchronous filesystem ops).
However if you are generating the mail you can change the requirements a
little - hence the removal of fsync ops.

As I understand xfs, using split_spool_directory is unlikely to buy you
anything.

> >      2. DNS lookups.  Having a good DNS cache nearby (local network at
> >         least) is a must unless you are only doing local mail ops.
> >         Personally I put dnscache ( ) on machines.


I missed the URL earlier - http://cr.yp.to/djbdns.html
>
> The DNS-Server is actually not the fastest around. I will install a
> bind-caching-server on a machine connected via crosslink-ethernet to
> enhance this.


> > RAM is not an issue
>
> I do not agree... After adding an extra 512MB the machine performed
> much better.


Maybe I should rephrase that - exim is not a memory hungry process,
although other things (databases, scanning) can make it so. Adding
extra RAM may help in terms of keeping disk data in RAM rather than
hitting disk. Given a slow server I might well add RAM because its
cheap at present, but I would not expect it to make a significant
difference unless the system had been pushed into swap, which is an evil
situation for unix servers.

--
[ Nigel Metheringham           Nigel.Metheringham@??? ]
[ - Comments in this message are my own and not ITO opinion/policy - ]