Doug White wrote: > qmail is also very inefficient when it comes to large delivery -- the fork > per message and the qmail-remote trigger-hitting will eventually > bottleneck you. It's probable you've run into it. My sympathies. :) You > might try *dropping* concurrencyremote somewhat to reduce the > context-switch thrash (although your context-switch numbers aren't too > high, I've seen worse and the machine wasn't taxed too heavily).
I was going to comment on this, but didn't; now that you have, though, I'll say that qmail is also not very good on connection reuse, so while it reduces average latency until it starts hitting resource limits (either local or remote -- some remote servers will throttle incoming connections from the same source, and rightly so, IMO), it has increased per message overhead. Not a problem to have 30% more overhead, until you start being starved of something other than network bandwidth, or hitting secondary effects of bandwidth limits (e.g. higher pool retention time on open connections, which uses more concurrent resources, cascading the problem). > It might be interesting to run top and find what the major culprit of cpu > usage is. Somehow I think it'll be qmail-send. Me too. 8-). My personal recommendation would be "try another MTA, even if you use the qmail MSA". My preference is sendmail; others will point you at postfix; in either case, the proof will be in the results you see from the switch, more than anything anyone can say to you. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
