on Fri, Feb 22, 2002, dman ([EMAIL PROTECTED]) wrote:
> On Fri, Feb 22, 2002 at 04:47:52AM -0800, Karsten M. Self wrote:
> | on Thu, Feb 21, 2002, Alan Shutko ([EMAIL PROTECTED]) wrote:
> 
> I agree -- it sounds like exim is forking lots of processes (one for
> each delivery) as it tries to deliver all the messages ASAP.  As a
> side effect, spamd forks that many times and takes a while to process
> the mail.  If the messages come in fast enough (faster than they are
> delivered) then the number of processes will increase.
> 
> | so your suggesting may be sane.  I trimmed my max messages accepted
> | from ~100 to ~50.  I've got exim running queue every five minutes,
> | which I think I'll cut to something like 2-3:
> | 
> |     /etc/exim/exim.conf: smtp_accept_queue_per_connection = 50
> | 
> | ...and the appropriate mod in /etc/init.d/exim.
> | 
> | If I understand properly, this should cause exim to attempt fewer
> | simultaneous delivers, and spread deliveries out over several minutes.
> 
> Looking at the spec just now, I think this is the option you want to
> tweak.  Another option that you may want to try is :
> 
> 
> queue_only_load               Type: fixed-point                Default: unset
> 
>     If the system load average is higher than this value, all incoming
>     messages are queued, and no automatic deliveries are started. If this
>     happens during local or remote SMTP input, all subsequent messages on the
>     same connection are queued. Deliveries will subsequently be performed by
>     queue running processes, unless the load is higher than
>     "deliver_load_max". There are some operating systems for which Exim cannot
>     determine the load average (see chapter 1); for these this option has no
>     effect. See also "smtp_accept_queue" and "smtp_load_reserve".
Interesting.

FWIW, I've got things working sanely at the moment.  I'd had exim
running from inetd rather that as a daemon, which might also explain the
many forkings.  Disabling inetd initialization and setting the queue
limit to 50 processes, with a queue cycle time of 3 minutes, appears to
strike a balance of manageable load and acceptable throughput -- 3-6
minutes to scan and deliver 200-300+ messages, with process count around
200-250.

Peace.

-- 
Karsten M. Self <kmself@ix.netcom.com>    http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?       There is no K5 cabal
  http://gestalt-system.sourceforge.net/         http://www.kuro5hin.org

Attachment: pgpfNs9RzoRiU.pgp
Description: PGP signature

Reply via email to