[ILUG] Re: Linux SMP on Xeons

[Brady, Padraig]

I'm sure you've looked into this, but an email
relay will have it's bottleneck in I/O I'd say?
What's the network interfaces on the system.
4 Xeons would be able to saturate a LOT of bandwidth,
if just relaying mail. 1 PIII should be more than
enough I'd say for 80,000 per hour. Give it gobs of
RAM though (512MB?). Are you doing anything CPU
intensive at all like virus scanning attachments etc?
	As for the MTA, I've used qmail on Red Hat 6.2
on 1 processor proliants. No problems what so ever.
For the qmail extra cool URL http://cr.yp.to/qmail.html

"Our busiest list is about 250 messages X 1800 subscribers (avg mail
deliveries: 
450,000 transactions per day). Sendmail was barfing badly on this, and qmail
seems 
to be doing real well. The machine is a Pentium 90 running Linux 2.0.13 with
64Mb 
of RAM. I have the spawn limit set at 100. I am *very* impressed." (Bill
Weinman)

I've also heard good reports of http://www.exim.org

> -----Original Message-----
> From: stalking mode [mailto:kitten at psophos.com]
> Sent: 15 June 2000 01:24
> 
> > Just wondering whether anyone has real experience of running
> > Linux on a 4- or 8- way Xeon system.  Any gotchas?  Does
> > performance scale well with CPUs?
> 
> No experience.
> From reading stuff in the past it appears as though the 2.2
> kernel does not scale well past 2 cpus (even 2?). This is one of
> the areas that 2.4 should improve on.
> 
> > The system in question is likely to be a high-performance mail
> > relay, running a carefully-tuned exim...  I'm hoping that, given
> > enough CPU and RAM (say 4 Xeons and 4GB), I'll be able to
> > handle something like 80,000 emails per hour.
> 
> <cartman>Sweet.</cartman>
> I know nothing about exim. Would recommend you have a look see
> at qmail as well. It's meant to be quite efficient at volume. If
> you do then have a look @ qmail.org for the section on
> high-volume sites (near the bottom of the page) to see if that
> will affect you.
> 
> > Reasonable?
> Dunno. Sounds nice.
> 
> Martin.