> > If many queue runners are active on a large queue, Exim appears to get
> > unfair by trying the same messages over and over, whereas others sit
> > on the queue untouched.
>
> Have you got evidence for that? How do you know the messages are
> untouched? Each queue runner should process the queue[*] in a "random"
> order. Every queue runner should look at every message on the queue
> eventually. If you have evidence otherwise, it is evidence of a bug.
Soemtimes, I saw messages that were on the queue for hours. They came in,
weren't delivered instantly due to high load at the time, and it took
real long until the queue runners got to process them. That means I
need more queue runners, but increasing their number a lot gives me the
"Spool file already locked" problem a lot, which means queue runners
just consume CPU time without doing anything useful.
Perhaps the randomisation is not random enough, but a central queue
runner would avoid the need for one.
> I have wishlisted this idea. However, I think that in practice, in most
> configurations, the number of clashes will be small, and it is only when
> there is a clash that this will make any difference. I don't really
> think it will get "way more efficient", certainly not in most common
> cases. For instance, if you have 5 queue runners, there will most likely
> be 5 clashes (or maybe a few more for new messages that are being
> delivered), but if you are scanning a queue of 1,000 messages that won't
> be noticed.
I have currently 300 queue runners working on queues between 20.000
and 100.000 messages. For a MTA not designed to do that, Exim works
fairly good, but to scale beyond, modifications are required.
Michael
