On Monday 11 November 2002 05:01, Philip Hazel wrote: > On Fri, 8 Nov 2002, Brett Thorson wrote:
> > Going to save you the spam of my eximwhat report, and try to summarize it
> > here. This is still pretty confusing. Here are the details for the
> > config I tried today:
> >
> > trusted_users = exim : majordomo
> > delay_warning = 0s
> > deliver_queue_load_max = 20
> > ignore_bounce_errors_after = 0s
> > return_size_limit = 10000
> > queue_only_load = 3
> > queue_run_max = 2
> > smtp_accept_queue = 10
> > strip_trailing_dot
> > remote_max_parallel = 10
> > queue_smtp_domains = *
> >
> > 100 Messages came in at 7:45AM. Each one of them started going through
> > the routing process. They came upon the queue_smtp_domains so no mail
> > was sent out. This is what I expected.
> >
> > After that completed, I think the deliveries started up. So I ran
> > eximwhat, and I see 183 exim tasks running.
> >
> > exiwhat | grep "waiting for a remote delivery subprocess to finish" | wc
> > -l 89
> > (Below is exim delivering messages to e-mail addresses)
> > exiwhat | grep "delivering" | grep "\-00 to " | wc -l
> > 89
> >
> > -------------------------------
> > So what I am trying to figure out is shouldn't I have at most 20 outbound
> > connections? Or does exim try to deliver one message, look in the
> > database for other messages that need to get delivered there, and it
> > tries to pick up that message? I think that is what is happeneing, but
> > since I keep hearing "exim has no central queue manager" I can't figure
> > out which one of my thoughts is wrong.
>
> If all is as it should be, there should be at most two queue runner
> processes, each of which should be running one delivery process, each of
> which should run up to 10 subprocesses, so yes, up to 20 connections.
>
> How many recipients are there for each of the 100 messages? I assume
> from what you've said that they have more than one recipient (otherwise
> you'd only get 2 connections). If Exim makes a delivery to one host and
> there are other messages routed to the same host, because of
> queue_smtp_domains, it will pass the connection on to a new process to
> send another message on the same connection, and the original process
> will continue making connections for its own recipients.
>
> However, (again assuming it all works as it is supposed to), the queue
> runner process that started the original process will not move on to a
> new message until the entire chain of messages sparked off by the
> original has completed. This is precisely to avoid firing up too many
> processes.
>
> Nevertheless:
>
> The new process should only do the deliver down the channel it has been
> passed, which means that the number of connections should increase by 1,
> but if there are lots of different recipients in the original message,
> and each one sparks off a new process for other messages, yes, I guess
> this is a way that a substantial number of extra processes could be
> created.
>
> Have you tried with queue_domains instead of queue_smtp_domains?
There are approximatly 4200 recipients for each message.
Ok, that explains it a little more clearly.
I have set the system to queue_domains = *
and will see how that runs
