On Thu, 15 Feb 2007, Alain Williams wrote:
> Is there any reason why local delivery is single treaded ? With modern
> multi CPU/core machines is might be nice to have a local_max_parallel
> option. Especially where address expansion results in lots of local addresses.
The original implementation of Exim was single threaded for all
deliveries; first the local ones (each in a separate subprocess, for
security, which was waited for before continuting), then the remote ones
(in the main delivery process, which changed from root to exim before
doing this).
Then remote_max_parallel was added - in Exim 3 it forked separate
delivery processes only if there was more than one remote recipient. In
Exim 4, it always forks, so the main delivery process no longer has to
change its uid.
The motivation for parallelizing remote deliveries was that a single
delivery can take a long time, so even with as few as two remote
recipients (to different servers), parallelism is a gain. My feeling at
the time was that local deliveries are quick, so I didn't bother to
change them. As far as I know, nobody else has questioned this.
Multiple local deliveries into normal file mailboxes will often be
hitting the same file system - whether this matters or not, I don't
know.
> This is my situation -- 4 CPU box & local delivery is to cyrus which
> will have 'wait' time while it is speaking to active directory; so a
> certain amount of parallel local delivery (in addition to batch_max)
> would probably make sense.
How are you delivering to cyrus? Using the lmtp transport? I suppose
that is the one local transport that could cause substantial delays.
(I guess pipe could too, if the pipe fills up...)
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
