spamd 3.0 does preforking of the child processes.

Nothing wrong with that, but WHY do the children have such enormous RSS numbers already when started (>20 Meg per process)? To me, this makes no sense.

3.0 has rendered two decent machines of mine useless by snarfing up all the RAM.


Can this be put back to the old fork-on-demand model? I'm convinced that the current forking scheme is broken.



Is the old 2.6x spamd code compatible enough to run with all the 3.0 perl apparatus?





Reply via email to