On Mon, 21 Jul 1997, Christoph Lameter wrote:
> How about omitting the "exim -q" processes and have the "exim -q30m"
> handle the queue as well? That would reduce the number of processes.
When you run "exim -bd -q30m", the -bd process is listening for SMTP
input, so it must spawn a new process to do the queue handling, because
it must not tie itself up for very long.
If you run "exim -q30m" without the -bd then I suppose it could avoid
one process spawning, but it would then not start a new one if the first
queue runner hadn't completed within 30 minutes (or it would have some
messy code to do that). As most people run with "exim -bd -q30m" it
doesn't seem worth the complication.
> One of the overhead is also that exim is spawning a new process for
> each message to be delivered.
I'm afraid that is fundamental to the design of Exim. I'm pretty sure
the amount of work done to effect a delivery far outweighs the cost of
spawning a process.
> I did
>
> exim -v -q hostname
>
> and it reconnected for each message to the host. Is it not possible to
> sent that via one connection?
(I presume you mean -R rather than -q?) This is a very simple way of
just picking messages off the queue by domain name. If the messages had
previously been routed and had failed to deliver, then they should have
been recorded in the spool/db/retry database, and as soon as one was
delivered, others should have gone down the same connection. If they had
not been routed, then this would not happen. I'm afraid Exim is designed
for a world where at least the routing can almost always be done.
I wonder if there is a problem with your spool/db/retry database? Can
you try running "exim_dumpdb <spool directory> retry" and see if it
manages to read it successfully? When was it last updated? Which DBM
library are you using?
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
