https://bugs.exim.org/show_bug.cgi?id=138
--- Comment #2 from Arkadiusz Miskiewicz <[email protected]> --- 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
