Benchmark: NetBSD 2.0 beats FreeBSD 5.3

[Ryan Sommers]

David Malone wrote:

>On Sat, Jan 08, 2005 at 01:21:14PM -0500, Charles Sprickman wrote:
>  
>
>>Any idea what type of impact this patch would have on say, a large qmail 
>>server that's drowning in context-switches?
>>    
>>
>
>It will depend on how many processes you have running at any one
>moment and how often processes are created/destroyed. From the look
>of the graphs, you won't really be able to tell unless there are
>significantly more than 1000 processes running at any moment.
>
>	David.
>  
>
This could be the case.

It's my understanding that Qmail spawns a new qmail-local process 
(specifically qmail-lspawn exec's it) for each locally delivered 
message. For any remote message qmail-rspawn forks a qmail-remote 
process. I don't believe these processes live longer than a single 
instance. Depending on how his mailboxes are setup this can even result 
in new processes being spawned. If you're running vpopmail qmail-local 
will pipe the message to vdelivermail. And if you're running anything 
like spamassassin from vpopmail (as opposed to from qmail via the 
QMAIL_QUEUE patch, although that will spawn a spamc of it's own) this 
could result in another executed process (spamc is spamd's light-weight 
front-end).

Depending on how large and busy this qmail server is, there could 
definately be a large amount of time spent in process creation and teardown.

I'm not sure how much Charles is familiar with the 
Qmail+vpopmail+spamassassin, if he is using spamassassin. But, one of 
the "hidden" features of using SpamAssassin and Vpopmail as installed 
from ports is that spamassassin is called from vpopmail. There is no 
run-time option (only compile time that is defaulted to on) to disable 
this. A lot of users don't realize this and will use the QMAIL_QUEUE 
patch and run spamassassin from it. This can result in scanning every 
email twice, which can be a costly oversight.

-- 
Ryan Sommers
ryans at gamersimpact.com