https://bugs.exim.org/show_bug.cgi?id=138
--- Comment #2 from Arkadiusz Miskiewicz <arekm@???> ---
Improved queue runner would be indeed welcome. Shared memory way or other.
Current runner is very bad for bigger servers/queues.
Example from my system:
exim -bd -q1s
mails in queue: almost 30k
queue_run_max = 5000
queue_only = true
mails are nicely delivered in a fast way, load on machine is about 10
Now when queue went below 5k (was about 3000 when I looked) the load jumped
over the roof to 600. Why? Because many runners were doing nothing but only
logging "retry time not reached for any host" and "Spool file is locked
(another process is handling this message)" and scanning queue - all that
causing huge I/O.
So exim is behaving much worse when there is a low number of emails in queue
than when queue is huge :(
Improvement is needed (for now partial workaround for above is log_selector
-skip_delivery -retry_defer but that's only workaround and looses information
about retrying etc; exim still looks at messages that it shouldn't need to look
because retry cycle didn't complete yet etc).
--
You are receiving this mail because:
You are the QA Contact for the bug.
