>> Yes, the situation I'm talking about is lots of spamd processes running >> at >> once using lots of memory. (Not to mention the local delivery processes >> running at the same time as well) >> >> Spamd using 800MB of ram is a bug, and one which I've never encountered >> yet in months of using spamd, so it's probably something to do with your >> particular config.....(perhaps a bug or corrupt installation of your >> version of Perl ?) > > I've encountered exactly this problem ever since upgrading to 2.60;
Nope, thats not the same problem he was talking about. He was talking about a single spamd process using 800MB, which is a bug and shouldn't happen. (And unless he's using heavily customized rules, I'd wager its a site perl problem, rather than a bug in SA) > several times a day my system suddenly goes from having 1 or 2 spamds > to having 40 or 50 of them. It goes into swap, the load average goes > up to sixty or more, and the machine grinds to a halt. > > I've set up a perl script to kill all spamds and restart the spamd > service if it sees more than 10 instances, but that's a hack - I'd > rather just see the problem solved... Well, the only problem is that you're allowing too many spamd's to run at once. "40 or 50" is *WAY* too many. Even on our server with 1GB of ram I don't allow it to run more than about 30 spamd's at once. Probably all thats happening is you get a sudden burst of incomming mail (possibly a spammer doing a spam run) and too many spamd's get launched at once, memory use pushes the server into swap, the swapping causes the server to fall behind the incomming connection rate, game over. This general problem has been discussed *many* times on the list... Are you using the -m option for spamd ? Are you limiting local delivery concurancy at the MTA level ? *ANY* server, no matter how grunty can be overwhelmed and pushed into swapping if the incomming connection rate is sufficient *unless* you set sensible limits to how many simultaneous copies of spamd (and/or MTA local delivery processes) can be run... Regards, Simon ------------------------------------------------------- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
