[Exim] Reducing number of Exim processes

Página Inicial
Delete this message
Reply to this message
Autor: Greg Ward
Data:  
Para: exim-users
Assunto: [Exim] Reducing number of Exim processes
Hi all --

I've tried everything I can think of to reduce the number of Exim
processes running simultaneously on our server in peak load periods, but
we still sometimes run out of processes on our server -- ie. can't fork
anymore.

There's really only one such peak for us: when someone approves a post
for a moderated discussion list that we run. It has 1981 subscribers,
1162 of them non-digest; it is run by Mailman, with SMTP_MAX_RCPTS = 20.

Thus, when a single post is approved, Mailman opens 1162/20 = 58 SMTP
sessions to Exim on localhost, and sends the same message with 20
recipients down each connection. There are 736 unique domains in the
1162 non-digest subscribers, so Exim has a fair amount of work to do to
get all those messages out the door. In order to avoid problems with
crazy load averages, running out of filehandles, and running out of
process space, I've enabled the following Exim options:

deliver_queue_load_max = 20.0
queue_only_load = 20.0

In order to keep the queue moving along at a good clip, I increased the
frequency of queue runs to every 2 minutes. To allow lots of parallel
queue runners once the initial peak in load average is past, I also set
these options:

queue_run_max = 20
remote_max_parallel = 20

This all works fairly well, but there are still problems with running
out of process space. In particular, this morning I approved a single
message, and shortly there after got this in /var/log/mail.log:

Jul 18 11:46:36 kronos spamd[3495]: connection from localhost [ 127.0.0.1 ] at port 43612
Jul 18 11:46:36 kronos spamd[3495]: cannot fork: Resource temporarily unavailable

... ie. SpamAssassin's spamd was unable to process a message (a bounce
resulting from the list posting, as it happens) because it couldn't
fork.

Anyone have any ideas how to reduce the number of Exim processes so that
other programs still have room to fork, while keeping the queue running
fast enough that it doesn't take several hours to completely deliver
each list posting?

        Greg
--
Greg Ward - software developer                gward@???
MEMS Exchange                            http://www.mems-exchange.org