John Hardin wrote:
Always 59 or more child processes?
Options notwithstanding, when things are running normally spamd seems to be managing child processes as needed - if a burst of processing comes in, new children spawn promptly, and slowly get killed over time as they sit around idle.
Bear in mind DNS lookup latency means your concurrency can probably safely be 2:1.
Mmm. Large messages take long enough to process that the regex crunching will outlive the DNS timeout, and scantimes on most other messages are ~1s or less (until there's a mail spike, at which point nominal scantimes climb up to maybe 2s).
At this point, I'd suggest (for no really good reason) try reducing min-children and see if it affects the behavior.
I've been pondering that for other reasons, in the interest of serializing mail processing a bit more so that *overall* throughput is higher at the slight expense of a whopping 5-10 seconds' delay on some mail on occasion. During major load spikes, we've seen mail go from a few messages per second to *hundreds* - curiously, all from netblocks owned by the same mail relay provider. Trying to push 200 messages through 16 physical CPU cores running SA does not parallelize well.
