http://bugzilla.spamassassin.org/show_bug.cgi?id=3839
------- Additional Comments From [EMAIL PROTECTED] 2004-10-20 22:27 ------- after discussing with perl5-porters, there was a suggestion as to what's happening: - spamd starts and reads config until 20MB ram is allocated - clears up and frees memory, leaving ~10MB in use (but 20MB allocated to the process) - forks children. each child gets a copy-on-write "copy" of that 20MB, including 10MB of allocated memory and 10MB of "free" memory that hasn't been returned to the OS - children process messages... - after several scans, the children have allocated and deallocated objects, eventually overwriting those "free" 10MB of pages, causing them to be copied into their own process. So in other words, there's 10MB of copy-on-writed, but free, pages being brought through the fork, making it look like spamd has higher memory usage and giving the kernel more pages to keep track of. If we could avoid those allocations early on, that would probably help. btw one tip from perl5-porters that may help: 'An approach that might benefit you is to serialise your data structures using some module such as storable, then recreating them in a fresh process.' Not sure how practical that would be, though, since fork() won't dispose of those pages; only fork()/exec() would. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
