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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
