Raul Dias writes: **snip > If I remember correctly spamd was using something between 2 to 5% of > memory reported by top (45 process max). > > If it was really shared, it would have not collapsed. > > My bet is that the model used on Linux is copy on write. So after a > fork, when the child spamd changes a value, the kernel makes its own > copy of the memory. (please correct me if I am wrong). To make it worse > perl script (AFAIK) is data and not code which makes harder to reuse > (espcially with evals around). > > Even if sharing does happen it is not enough. > > OTOH, with an I/O model, the total memory used would be: > - the perl interpreter and libraries (this is trully shared on a fork > model). > - the compiled perl code and perl libraries. > - one copy of the parsed rules and compiled regular expressions and non > message/scanner related data.
Yeah. It's the lists and rules and regexes that do it for me. > - one M::SA::PerMsgStatus object for each simultaneous scanned message > (this is a place to put a limit on). > >> Still, if someone tries it and can demo increased efficiency... >> go for it ;) > > This might require some internal changes to SA. Every Sync call would > have to be changed to Async (NON BLOCKING). This might include SQL > calls, DNS calls, exec ing external apps and even file I/O. An async version of Net::DNS is http://search.cpan.org/~msergeant/ParaDNS-1.1/
