Re: Spamassassin, fetchmail, exim, and system resource issues

[dman <dsh8290@rit.edu>]

On Fri, Feb 22, 2002 at 04:47:52AM -0800, Karsten M. Self wrote:
| on Thu, Feb 21, 2002, Alan Shutko (ats@acm.org) wrote:
| > "Karsten M. Self" <kmself@ix.netcom.com> writes:
| > 
| > > When pulling mail, I'll see the system spike to 350 or more processes.
| > > It appears that each mail delivery initiates a separate exim process
| > > (which I hadn't expected) and procmail process (this I had).
| > 
| > I don't send fetchmail's output through exim, I just put this in
| > .fetchmailrc
| > 
| > defaults mda "/usr/bin/procmail -f %F"
| > 
| > which serializes mail delivery.  So instead of hitting user limits, it
| > takes a while to go through morning mail... maybe I should try
| > spamd....
| 
| spamc/spamd is highly recommended.
| 
| I think the problem is exim's handling moreso than the others,

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".

-D

-- 

Micros~1 :  
 For when quality, reliability 
  and security just aren't
   that important!