Hi Rob,
Rob Gunther <redrob@???> (Do 09 Apr 2015 15:26:18 CEST):
> In our normal day-to-day we have maybe 2,500 messages in the exim queue at
> any time. We retry delivery every 15 minutes, slowing down the retry as
> messages gets older.
…
> When the queue got down to maybe 90,000 messages I found the speed that
> Exim was processing seemed to be increasing, started to time and see how
> many messages it was doing per minute.
>
> At 85,300 messages in the queue it did about 480 deliveries per minute.
> At 67,775 messages in the queue it did about 785 deliveries per minute.
> At 40,458 messages in the queue it did about 1,227 deliveries per minute.
A single queue runner process isn't very fast. The master process spawns
new queue runners on a regularly basis (15 minutes in your setup?)
Thus I'd assume that in the beginning you had just one queue runner,
after a while 2, then 3 and so on… sending more messages/minute.
> I have read on here that Exim does not do well with a large queue, is my
> observation normal? The bigger the queue the slower the processing?
I'd say even with only 2500 messages in the queue you won't send more
than 480/minute (the 480 isn't a fixed number, I copied it from your
observations, the rate depends on lots of factors: DNS lookup, file
system bottle necks, locking of the hint files, …)
> How could I have handled that massive amount of mail automatically, I want
> to see those messages flying!
You may try to start more queue runners at once, manually… Or try to
use -q5s as a parameter for the daemon, it would ask the daemon to
spawn a new queue runner every 5 seconds.
> Is there a way to configure Exim to stop accepting mail if there is so much
> in the queue? Maybe if there is 75,000 message in the queue we just refuse
> to accept anymore because there is obviously a problem and adding more to
> the queue is just going to make things worse.
Acceptance can be dependend on the load of your system, but I think
there is now number/expansion item with the numbers of queued messages…
Because the listener can't know about the queue. There may be even more
systems putting the messages into the same (shared) queue. Currently
Exim maintains no simply and cheap way to get the number of queued
messages.
But - of course you can do something like this:
acl_check_connect:
defer condition = ${if <{2500}{${run{$exim_path -bpc}}}}
But it may waste ressources for counting the messages..
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
