We experienced a similar problem on FreeBSD. The problem was addressed when we upgraded perl from 5.5 to 5.8. As a workaround until we managed to upgrade we launched spamd under the control of Dan Bernstein's Daemontools which can be configured to automatically impose limits and restart misbehaving processes.
I did that as well, and it does help, as daemontools has a much lower overhead than xinetd, but it did not solve my particular problem.
I had spamd processes going over 90Meg each, which was hampering our mail delivery ability... what fixed my problem with memory utilization is disabling auto-whitelisting. Once I did that, spamd doesn't go over 30 Meg.
Also, if you're using ifspamh, it sometimes barfs on large files causing their delivery to be deferred. I basically rewrote it in Python (been a bit busy over the holidays to make sure it's ready for prime time) where it does it's own delivery, and that has worked well.
If you want to see the code, email me privately and I'll get you a copy. Keep in mind it's very specific to my site (I have a custom mail delivery backend integrated into my qmail) but it shouldn't be too hard to generalize.
System: SA 2.60, Perl 5.8, RH 9, qmail, Athlon 1800+XP & 1G Ram
HTH, Roger "Merch" Merchberger
-- Roger "Merch" Merchberger --- sysadmin, Iceberg Computers Recycling is good, right??? Randomization is better!!!
If at first you don't succeed, nuclear warhead disarmament should *not* be your first career choice.
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
