Right now I am still having troubles with exim processing huge queues.
exim -q processes one message at a time. So the time needed to process the
queue is the time needed to contact all hosts on the queue. Those
hosts on the queue were usually queued because there were some connection
problems (usually timeouts!). The time to process the queue can be
extrodinary therefore.
The default timeout for a "connect" attempt is 5 minutes. Lets say I have
1000 messages waiting on the queue and all those hosts timeout then those
messages (worst case) will take 5*5000 = 5000 minutes to process. That is
already around 100 hours!. I noticed that it can take up to 15 minutes for
exim to give up contacting a host under Linux!
I think exim needs some way to insure that queue runs are done in a
determined time interval. Lets say I do
exim -bd -q30m
Exim should make sure that every message will be checked within 30
minutes.
I know that additional queue runners will be started over time but it
seems that they did not much good. I have had messages bouncing after 6
days or so when the system finally came back to that message...
I had around 10.000 messages on the queue today (rest from 210.000
deliveries yesterday when the internet developed some trouble with a lot
of hosts in the .com domain).
What I did to work around this is to change the timing parameters for the
SMTP transport and let all those problem messages be forwarded to a
different host. That way at least the queue was worked over (running
multiple queuing processes of course). Now they are on a different host. I
hope I do not have to play the same game from this host to another.
# Do a fast try and then move it over to the fallback host.
smtp:
driver = smtp;
fallback_hosts = 206.1.27.6,
command_timeout = 10s,
data_timeout= 20s,
connect_timeout = 5s
end
