Hi Tom, > We have had a couple of instances recently where our mail server became > severely overloaded, with many spamd processes running. [...] In each > case, we had around 150 spamd processes running, with 2.5 GB of swap in use > on a machine with 250 MB of memory! > > Each time I noticed that although there were around 150 spamd processes, > there were only around 3 spamc processes. How is this possible?
I noticed the same issue on a RedHat-7.2 box with SA-2.54, Perl-5.8.0 and Sedmail-8.11.6 (patched). I called Spamd with the options "-d -a -c" and Spamc was called from within /etc/procmailrc in that setup. Now if a user on that box has exceeds his allocated disk quota, then Spamc can't deliver the mail to his mailbox. Result: Spamc bugs out properly, the Procmail child which called Spamc ends as well after a few seconds and the mail bounces. All that is just fine up to that point. BUT: The Spamd child forked for the delivery of that email remains around indefinitely. :o( So each email to a user which is over quota will properly bounce, but the Spamd child process associated to that delivery stays behind, taking up precious ressources. A few dozend bounces like that and the cpu & memory usage go straight through the roof. I have no idea why Spamd does that, or how to fix it. This behaviour isn't exactly new and I noticed it as far back as SA-2.41, which I was running on the same box, but with Perl-5.6.0 instead of Perl-5.8.0. As a work around I stopped using Spamd/Spamc and now pipe all mails directly through /usr/bin/spamassassin instead. With the usual performance drop associated to that delivery method <sigh>. -- With best regards, Michael Stauber ------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
