Matt Kettler wrote to Giuseppe Perricone and [EMAIL PROTECTED]:
> At 04:58 AM 6/24/2004, Giuseppe Perricone wrote:
> >- spamassassin options
> >SPAMDOPTIONS="-x -d -u spamd -H /home/spamd -D"
> >
> >Someone have the same problems or know how to solve it?
>
> use the -m parameter on your commandline to spamd. See the manpage for
> details.
Hi Matt,
This happened to us this morning, too. We're using:
/usr/local/bin/spamd -a -x -r -m 10 -u mailnull
Normally, the server runs with ~60 processes. Within a few minutes, the
system (FreeBSD 4.9-p10, SA 2.63, sendmail, spamass-milter, PIII-1.1GHz,
512MB RAM, 512MB swap, started running out of swap space, with over 400
processes (which I *assume* was some combination of spamd/spamc/
spamass-milter, and sendmail children, but it was nigh impossible to do
any "live" forensics), and *veeeery* sluggish as a result (2-3 minutes
for local echo, and SMTP was taking a few minutes to report "Try again
later" after the DATA was sent).
The one thing I *did* see, however, was an amazing number of spamd
processes dying and being recreated, before swap space was exhausted. We
cycled through ~50K processes in a few minutes.
We decided a reboot would be the quickest way to regain a working
system, so we did. When it came back up, the load averages began to
quickly climb again, but I didn't see more than 10 spamd processes this
time.
So, before things spiralled out of control again, we disabled network
checks (-L), and have returned to 2-3 spamd processes and good response
times... so I'm guessing one or more of the network checks are timing
out and causing all sorts of thrashing.
At the moment, I don't think this is a SA problem per-se (unless I can
verify that there were, in fact, too many spamd processes running, but I
haven't done that). It may be that we just need to throttle sendmail a
bit (in terms of max. children), due to the unusual memory requirements
seen when one of the remote checks starts timing out. Even as it was,
our queue grew by a few orders of magnitude. ;-)
How hard would it be to have spamd "keep state" with the remote checks,
so that if one starts timing out, that it would use some capped
exponential backoff algorithm to exclude that server from *future*
checks across other spamc/milter sessions? That way, spamd would do a
lot less waiting, and keep a lot more mail moving, without intervention
(i.e, -L).
Thanks,
- Ryan
--
Ryan Thompson <[EMAIL PROTECTED]>
SaskNow Technologies - http://www.sasknow.com
901-1st Avenue North - Saskatoon, SK - S7K 1Y4
Tel: 306-664-3600 Fax: 306-244-7037 Saskatoon
Toll-Free: 877-727-5669 (877-SASKNOW) North America
