The docs for queue_run_in_order say:
Thus, setting queue_run_in_order with split_spool_directory may degrade
performance when the queue is large.
and then
In most situations, queue_run_in_order should not be set.
I'm a bit curious about this:
* how large is large? the system where I'm considering enabling
queue_run_in_order typically has 1000 .. 2000 messages in
the queue; I've seen it as low as 600 and as high as 6000
(when the local DNS cache was on holiday) I assume this is
*not* a large queue.
* is the general admonition against queue_run_in_order a result of
the possible performance degradation? or are there other good
reasons not to use queue_run_in_order?
I did have queue_run_in_order enabled for a few days back in May, and my
vague, subjective impression was that new messages tended to sit in the
queue before any delivery attempts for longer than they had previously.
(I also have the load-average limiting options enabled here, so there
are always a couple of outgoing list messages that haven't started
delivery yet.) Is *that* why queue_run_in_order in discouraged?
Thanks --
Greg
--
Greg Ward - software developer gward@???
MEMS Exchange http://www.mems-exchange.org
