https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7342
--- Comment #4 from RW <[email protected]> --- Processing an email on my desktop takes several seconds of core time, over 4 cores it can sustain ~ 1 per second. With network tests a child process can spend a lot of it's time waiting, in which case you may need several child processes per core to be cpu limited (for test purposes it's nearly pointless to do to new network look-ups on old email any). Compared with this starting-up a small binary and a socket connection is negligible, it scales well under normal use on a mail server. Fairly obviously if you bypass the limits an MTU would provide, and fire-off new spamc processes orders of magnitude faster than spamd can process them it wont scale well. A simple way to throttle it is to run spamc -K > /dev/null in the foreground for every few background spamc process. This only requests the version, but the request is still assigned to a child process, so it blocks until it gets one and then returns instantaneously. An alternative is to to run several parallel instances of the spamassassin script in batches. It's less flexible, but it's convenient for n-fold cross-validations in particular. In future it would be better to take this kind of thing to the user list first. -- You are receiving this mail because: You are the assignee for the bug.
