On 2013-08-19 at 18:19 +0800, boyd yang wrote:
> Thanks!
> I find more detail about loadavg here:
> http://www.loadavg.com/2012/01/procloadavg/
>
> I think deliver_queue_load_max here mean the first number:
> root@mail:/etc/exim4/conf.d/main# cat /proc/loadavg
> 2620.41 1627.96 962.37 1504/13290 4940
Yes, that's your load average, given in the first three fields over 1, 5
and 15 minutes. (The portable way to see these is with the "uptime"
command, which works on every Unix).
The next field says that you have 1504 processes "runnable", ie
competing for CPU, out of 13290 processes on the system. The last field
is merely which pid was most recently scheduled to run.
Unless you have a monster of a system, this is basically saying that
you are starting too many processes at once.
> root@mail:/etc/exim4/conf.d/main# cat /proc/loadavg
> 2620.41 1627.96 962.37 247/13354 5200
That, though, shows that most of the processes switched out of runnable
state, but without completing, so are probably then blocked on I/O.
How much mail volume is this system handling? Is the system dedicated
to email? If you run "ps", and look to see what's running, is it mostly
Exim, or some other command?
ps axo cmd | cut -d ' ' -f 1 | sort | uniq -c | sort -nr | head
That should give you the top ten processes, by command-name.
If this load is mostly Exim, I suggest setting:
queue_only_load = 10
and vary 10 to be "a bit more than the number of CPU cores in the
system" (as a "wet finger in air" first pass guess) so that if the load
is high, when receiving messages, then the mails will only be queued and
no immediate delivery attempt will be made. Instead, queue-runners will
handle deliveries, and you might change the Exim command-line flags to
start queue-runners every minute, and those will then be subject to
"queue_run_max" and constrain the concurrency of delivery. This should
help you avoid a death-spiral of the system contending with itself, by
running fewer processes which each try to get more done, sacrificing the
(failing) attempts to be more "immediate".
As a result of the queuing, if you have a lot of mails for common
destinations, then you'll start more routinely sending multiple messages
down one SMTP connection, which might change the behaviour you're used
to and this may lead you to change some of the other tuning options.
If the load is mostly spam or virus scanning, then your best bet is to
limit how many concurrent incoming connections you accept in Exim, to
constrain how many scanner processes you end up starting, in which case
you want to adjust "smtp_accept_max" and "smtp_accept_max_per_host".
-Phil
