Hi Brian
Thank you for the reply and the time taken to convey your thoughts.
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.
>> will have a look at the log files to see exactly why it's not getting
delivered and let you know if I need some more help here...
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.
>> I have that option enable and set to 100 - would that setting be adequate
??
Make sure you have a queue runner daemon: e.g.
exim -bd -q30m
^^^^^
>> I have made sure that I have that option included in the /etc/init.d/exim
file. How would I know that the queue runner is actually running ? When I do
a ps -aux ,, all I see is exim processes in this form :-
exim 24319 0.0 0.1 7124 2280 ? S 09:27 0:00 [exim]
root 24324 0.0 0.0 7052 1848 ? S 09:27 0:00 [exim]
I don't see a specific one [exim -db -q30m] and I'm not sure if I should
actually see one like that... ??
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)
>> I have included some exim stats for busy days, files attached (t.2 t.6
t.7)
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).
>> I take it we will not gather enough information around the IOSTAT with
doing one just now, but let me post it in any case :-
Linux 2.4.20-8smp (mx01.gam.co.za) 28/04/05
avg-cpu: %user %nice %sys %idle
15.24 0.00 4.25 80.51
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
dev8-0 73.47 497.85 171.52 3772606540 1299741856
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!
>> as far as I know, no one has the setting enabled to leave messages on the
server. How would I know if someone has that option enabled ??
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.
>> We are running MySQL on a total separate server. Although the server is
taking some train if I look at the loads, none of mail is put on the queue
because Exim can't access the MySQL database.
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.
>> I will keep these rules in mind and perhaps put some of them into play
when we get a new mail server.
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.
>> POP connections are a major problem for us at the moment as most of our
users set their mail clients to check for mail every 1, 2, 5 or 10 minutes
(or whatever they like) which is perhaps why some of the mail gets queued
because people are constantly checking mail that puts a lock on the mail
boxes.... The question is.. How do we limit that ??
>> Thanx for all the help !!
RC
HTH,
Brian.
--
## List details at
http://www.exim.org/mailman/listinfo/exim-users
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://www.exim.org/eximwiki/
