On Wed, Apr 27, 2005 at 01:21:25PM +0200, RootChaos wrote:
> I need some help with perhaps a general config tweak or perhaps some
> completely new suggestions.
>
> We have a mail server with the following configuration :-
>
> Exim 4.30 (MySQL Database backend - Virtual Mailboxes)
> Amavisd-new
> F-PROT Antivirus
> Spamassassin
> Qpopper
>
>
>
> Hardware Config :-
>
> Dual Intel P4 2.8
> 2 GIG Ram
> 1 x 120 GIG IDE Hard Drive
>
>
> Currently we have about 6000 mail boxes on the server. We seem to be running
> into some very heavy queues of mail not being delivered to the mailboxes on
> the local server. This starts at about 8am in the morning when mail seems to
> be queued on the server, some of them for even up to 8 hours.
The first thing I would do is look at your exim log files to see why the
received messages are being put into the queue, instead of being delivered
immediately. You may find options like smtp_accept_queue_per_connection
helpful here. Or you might find some other reason why messages are being
deferred, for example mysql rejecting queries at routing time.
Make sure you have a queue runner daemon: e.g.
exim -bd -q30m
^^^^^
What's of more interest than the number of mailboxes is the number of
messages being delivered per hour; analyse your logs to find this out
(exicyclog and eximstats are useful here)
You have a single IDE disk, and that may well become a bottleneck. Typically
you will be able to do no more than 100-200 disk operations per second
(assuming a 5-10ms average seek, for a reasonably modern disk). Mail
deliveries will involve multiple synchronous writes to exim's queue
directory and writes to the mailbox files. Monitor the number of disk
accesses per second being handled by the drive (under FreeBSD, 'iostat' and
'gstat' are your friends; I don't know the Linux equivalents).
You are using mbox files. Depending on your user's usage patterns for
reading their mail, you may find Maildir to be more efficient. For example,
if people tend to set "leave mail on server" and have 10MB of mail in their
mailboxes, then every single POP3 login will require the pop3 daemon to read
their mailbox file from start to finish, just to count the number of
messages it contains!
Furthermore, mbox files rely on locking. If someone has their mailbox open
for a long time in a POP3 session, that *might* cause exim to defer the
delivery. Your log files should tell you this. Maildir doesn't have this
problem.
You have 6000 users. You're using a mysql database, which is better than a
linear password file, but make sure mysql has all the resources it needs. In
particular, make sure that if it limits the maximum number of concurrent
client connections, that limit is high enough. Otherwise exim processes may
find themselves unable to open connections when they need them, and start
deferring deliveries.
The general rules I use for improving performance on a mailserver system
are:
- spread your users across multiple disks
- use SCSI disks if possible. If you must use IDE disks then put each one
on a separate IDE interface (i.e. don't configure master/slave pairs)
- if you want redundancy, use mirroring instead of RAID5
- put as much RAM in as you can afford
- stick your Exim hints database on ramdisk
- use Maildir instead of mbox (that requires you to reconfigure or change
your POP3 server, of course)
- use a filesystem which handles synchronous metadata writes efficiently
(e.g. FreeBSD + UFS + softupdates. Perhaps some of the Linux journalling
filesystems will work well here, but I don't have experience of those)
- build a test environment and check how many messages per minute/hour you
should be able to deliver, and tweak it to optimise. A useful tool is
http://www.coker.com.au/postal/
Then if your live system doesn't perform this well, you have something
to benchmark it against.
- shouldn't be an issue these days, but never use ISA network cards or
disk controller cards! Stick to PCI.
And as well as monitoring Exim, make sure you monitor your pop3 daemon
carefully too. How many connections per minute do you get at peak? How many
concurrent connections do you get at peak? How big are your users mailbox
files? And so on.
HTH,
Brian.
