On Sat, Jan 31, 2015 at 06:11:20PM +0100, Andrew Bourgeois wrote:
> > > My question is: why is that?
> >
> > Because of the difference: one message, instead of all.
>
> So it's done because of performance reasons?
No, for protocol reasons. The external queue manager protocol
by which pickup, cleanup, and postqueue signal new activity
is very simple, just one byte "trigger" messages. As documented
at
http://www.postfix.org/qmgr.8.html
D (QMGR_REQ_SCAN_DEFERRED)
Start a deferred queue scan. If a deferred queue scan is
already in progress, that scan will be restarted as soon as it
finishes.
I (QMGR_REQ_SCAN_INCOMING)
Start an incoming queue scan. If an incoming queue scan is
already in progress, that scan will be restarted as soon as it
finishes.
A (QMGR_REQ_SCAN_ALL)
Ignore deferred queue file time stamps. The request affects the
next deferred queue scan.
F (QMGR_REQ_FLUSH_DEAD)
Purge all information about dead transports and destinations.
W (TRIGGER_REQ_WAKEUP)
Wakeup call, This is used by the master server to instantiate
servers that should not go away forever. The action is to start
an incoming queue scan.
Since postqueue(1) (via flush(8)) can't tell qmgr(8) which message
to retry, flush(8) moves the message to incoming/ instead, and
sends a QMGR_REQ_SCAN_INCOMING trigger.
> Do the flushed deferred e-mails have priority over the messages that reside
> in the incoming queue? or is it round-robin like when you wait for a
> message to hit the minimal_backoff_time?
The queue manager is round-robin when both incoming and deferred
queue scans are in progress. When only one of the two is being
scanned, then the round-robin is not applicable.
But none of this will help you improve performance. The queue
manager is single threaded and either I/O bound (reading directories,
calling stat(2) to determine which files are ready for processing,
moving queue files from deferred/ or incoming/ to active/, opening
and reading them to determine the recipient lists, ...), or it is
blocked on trivial-rewrite to perform transport table lookups and
the like. The latter only dominates when perhaps transport lookups
are via SQL or LDAP to a remote machine.
A RAID controller with a battery-backed cache is the best way to
get fast metadata updates that might speed up the queue manager.
For read performance, faster disks, more spindles, ...
--
Viktor.
