> On Tue, 5 Oct 2004, Jon Trulson wrote: > >> On Mon, 4 Oct 2004, Luis Hernan Otegui wrote: >> >> > Well, a weekend update: >> > Nothing has changed here. I removed EVERYTHING (except for local.cf) >> > from /etc/mail/spamassassin, and still it chews as much memory as it >> > could get. I limited the number of childs to five (removed the -m >> > switch in the startup script), and nothing changed. The only >> > "improvement" was that instead of 20 processes claiming all the >> > memory, there were only five trying to freeze my box... But the oldest >> > one still is a big memory grabber: It reached up to 133 MB, and NEVER >> > got any lower, it just keeps grabbing and grabbing memory... Seems >> > pretty much strange to me... >> >> Same thing I saw, except in my case, it was 320MB. Once a child >> had it, it never let it go until terminated (or hit the default 200 >> connection limit). > > Is there a Perl equivalent to the Unix 'setrlimit' or 'ulimit' > function? (IE something to set the max data size that a process is > allowed to use). > > Just set it to limit the child processes to something reasonable, > (say 50~100MB) and have them die if it is exceeded.
Is there any reason why you couldn't just use the unix ulimit command in the script that launches the spamd daemon ? Are the spamd children threads or processes ? If they're just forked processes, shouldn't they inherit the ulimit values of the parent ? If one of them went over it's ulimit it would be killed. Whether the message being processed would then pass through unscanned or not, and whether the parent spamd would notice and respawn a replacement is another matter though... :) Regards, Simon
