https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5858
--- Comment #4 from Joao Gouveia <[EMAIL PROTECTED]> 2008-03-20 10:46:08 PST --- (In reply to comment #3) > hi -- > > I think you've run into a problem with perl itself; as far as I know, whether > or not the perl interpreter returns freed memory to the OS, is up to the > malloc() library in use. In my experience on Linux, it never returns this > memory (or at least never returns in a way visible to "ps" or "top"). I am aware of that, but this doesn't explain the huge diference from a "normal" message to the sample i've attached. > We get around this in spamd (and our mass-check script) by using child > processes to do the check() operations, which exit after scanning several > hundred messages. this way the "spare" memory usage is cleaned up when each > child exits. That's how things work here also. A pool of preforked children do the work and die after N checks, where N is tipically set to 1000. This has been worked fine so far, but yesterday that "problematic" messages came in and processes started to grow allot more fat that they're supposed to. This eventually caused OOM to trigger (10 workeds, each one with > 600Mb RSS eventually made the box stall) > There's a possibility btw that the "spare" memory usage is more or less > harmless -- in that it is unused by the process after it is freed by perl, and > therefore paged out once there's any swap pressure. but it's certainly not > good to have. > That's not what I'm seeing here. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
