john.connor@??? said:
> Clearly this is not good. I have been running with a slighly modified
> out-of-the-box config file with mods to cope with the way we
> authenticate messages. Exim on this box is dealing with 200,000
> messages a day. I note from Yann's postings earlier that they are
> dealing with millions of messages.
Actually planet's config scales sideways rather than making the box
bigger precisely because you run out of IO power long before you run
out of CPU.
Exim creates 3 files per message (headers, data, message-log). Since
the first 2 of these files are created as safely as possible (ie make
sure the data is in them and flushed to disk) before a message is
accepted, the maximum throughput of a system is normally defined by the
filesystem/disk-subsystem - specifically the number of committed file
creates/writes you can do on a system. With only 2 disks, in a
mirrored config, you are *seriously* IO bound on disk - you really only
effectively have a single spindle (the second effectively has to follow
the first - the main effect if you have probably reduced your SCSI
bandwidth).
[Incidently this also shows why postfix when optomised into the ground
will outrun exim in theory - it only uses one file per message - but
real world is never well defined by theory or benchmarks]
exim-users@??? said:
> Try to find out if the bottleneck is the spool or the config files. If
> it is the spool and you have lots of mails sitting there for a long
> time, waiting for delivery to external systems, send them over to a
> separate host and deal with them there.
Config file are rarely a problem - unless you are short of memory - if
they are read often then they tend to sit in your OSes file cache. If
you use decent indexed lookups its even better, if you use cdb on a
decent OS then all the cdb files will be memmapped/shared.
exim-users@??? said:
> Also you could try to put the configuration data on a RAM disk.
> Although I never tried this, it could help you. Obviously this is not
> a good idea to do with the mail spool.
This won't help - if you have enough RAM to do this, then config file
caching won't be a problem.
In general its a case of making your spool (transit rather than
necessarily delivery) as fast as possible, so new disk for that -and
you can do the calculations on whether you need to mirror, stripe etc
depending on how you count the probabilities of failure and
consequences thereof.... Putting the spool on a hardware RAID system
with decent NVRAM caching certainly should be a serious option, and
examining your choice of filesystem to ensure that has the best
combination of performance with integrity for your needs (and you may
also get things like BTREE directories which could really help if your
directories get fat).
Nigel.
--
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]
