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
pgpfNs9RzoRiU.pgp
Description: PGP signature