Slashdot Mirror
Benefits Of Multiple CPUs With Samba?
PirateBek asks: "We're considering putting in a sizable Linux box to serve our entire campus via Samba. We can save quite a bit of money by going with a fast (PIII-800) single CPU, or spending more for dual slower (PIII-667) CPUs. Is going with two slower CPUs worth the inital dough, or will a faster CPU make up for the added benefit? Does Samba tend to like dual CPUs, or does it really matter? Mind you, we're working under a tight budget, and we want to get the most bang for our buck. Any experience/knowledge in this arena would be quite appreciated."
The single best reason I can think of to go with a 2 CPU solution is to allow you to run virus scanning on the server. Since you are using Samba, I'm going to got out on a limb here and guess that you are serving up files to Windows clients. I wouldn't think of running a file server for Windows machines that didn't have a good virus scan in place.
A well thought out anti-virus solution will have scanning at every possible point (mail gateway, client machines, file server, etc...)
There are anti-virus solutions that run on Linux and a second CPU would definitely help out if you decide to do that.
You no longer have to buy a proprietary x86 OEM solution to get massive, multiple memory and PCI busses for high I/O throughput. The new ServerWorks (formerly Reliant Computer Corporation) ServerSet III-series chipsets are making their way onto retail mainboards from major vendors. They put the disk controller on a different PCI bus than the Ethernet controller.
For those interested, here is a comparison of various chipsets and their aggregate memory and PCI throughput in MBps, respectively (sorry about the format but ./ doesn't seem to allow tables or the pre/code tag):
Again, this is just aggregate throughputs. RDRAM is faster at bursts, but SDRAM has lower latency (i.e. better), and the old EDO of the i450NX chipset doesn't even get close to what SDRAM and RDRAM can do.
But note the massive PCI throughput of the ServerSet chipsets from ServerWorks -- due to their 3 independent PCI busses, of which, 2 are 64-bit (both are 66MHz capable in the HE/WS). They're so good, that even Intel is adopting the 4-way IIIHE for a forthcoming SDRAM server mainboard instead of RDRAM. This is largely because the 4 RIMM slot i840 can only support upto 2GB of RDRAM whereas the 16 DIMM IIIHE can support 16GB. As of right now, all Intel can offer for servers is the 3-year old i450NX so most tier-1 vendors have opted to work with ServerWorks instead.
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
Samba runs more than one daemon to handle different types of requests. Having multiple CPUs lets the daemons communicate more effectively than having them share one CPU. I think the slower dual-CPU setup is the way to go. Ideally, you'd like smbd to remain in cache on one CPU while the other pops around between nmdb and the kernel filesystem layer. Multiple CPU's let processes with multiple threads to work more effectively and that's exactly what you have with a fileserver.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
grep s.*m.*b /usr/dict/words
didn't work on my linux box but worked on my school account on a solaris machine
All other things being equal, you're right.
But since the poster says his budget is limited (as everyone's, I suppose), he has to make some trade-offs. Very generally speaking, if most of the tasks are CPU bound, you'd better get lots of CPU power (more CPUs and/or faster CPUs). If mos of the tasks are I/O bound, you will get better performance with somewhat less CPU and more I/O troughput (fast HD, fast bus, fast NICs).
In this case, I think I/O is more important than CPU, so I would go for a single CPU machine with SCSI HD's.
This sig under construction. Please check back later.
Well, our main goal for the samba box will be network storage, network printing, and possibly tie it all in with a web front-end. We may actually be hooking in database information, but all of that will be processed on a much bigger box.
We'll have about 1500 users, with maybe 150 connected at any one time. The system will likely have a gigabit uplink to the main switch, or at least a 100-base. The rest of our network is fast and reliable, so we're not concerned about the connectivity.
As we'll not be using the system for a lot of processing power, I guess the second CPU might be money spent unwisely, unless you think differently based on the information I just added. The VA Linux box will/does have the option of adding a second CPU at another time, so if need be, we can toss that in and recompile.
I'd love to get something better than an Intel box to run this on, but our budget is way too tight. I figure the 133 mhz bus on the PIII will likely do fine for now - hopefully.
/me strokes beard.
Hmm...lots of folks are getting rid of their Alpha's cuz they won't run Win2K...hmm...
Well, we're not "Intel Whores" (hehe)...but we like the options that VA Linux gives in rackmount systems. If there are other vendors out there that can provide an AMD solution that is rackmount, and can certify that their RAID solutions will run with Linux, I'd love to find out.
We'll likely have a RAID5 array of LVD disks, and we're expecting to have about 150 connections at any one time, but Xeon is definitely not a price option.
I would love to see us move towards an Athlon platform. I've been using AMD for quite some time on my home systems, and I feel quite confident in their CPUs.
...this one is.
-kalrand
the voice of reason
That posted at 2. That's funny since I don't have enough karma to do that. What's going on here?
Keeping
..last post?
Mr. Last Post
The word list included with Linux, /usr/dict/words, is only 45402 words long.
. html
Try:
http://www.puzzlers.org/secure/wordlists/dictinfo
They have lists with over 200,000 words. Samba is definitely included.
Firstly, that's not proper syntax. It would have had to have been either:
grep "s.m.b." /usr/dict/words
consumable
presumably
resumable
somebody
Or maybe it was
grep "^s.*m.*b.*" /usr/dict/words
scramble
scrambled
scrambler
scrambles
scrambling
semblance
shambles
slumber
slumbered
smokable
smoothbore
somber
somberly
somebody
steamboat
steamboats
stumble
stumbled
stumbles
stumbling
succumb
succumbed
succumbing
succumbs
symbiosis
symbiotic
symbol
symbolic
symbolically
symbolics
symbolism
symbolization
symbolize
symbolized
symbolizes
symbolizing
symbols
No "samba" in my /usr/dict/words. Maybe it was a custom entry, or maybe this is must a myth.
--
Actually, truth be told even an old Pentium-II 233 can keep a Samba network VERY busy.
Mutliple CPU's can be helpful on a minor scale for a couple of reasons:
Your biggest performance improvements will probably come from doing a few basic things right:
sigs are a waste of space
You will gain some performance by using SMP, but if you've got the choice, go with a single-CPU machine with the fastest I/O subsystem you can get for the same cash as the SMP box. It'll give you much more bang for your buck.
The main question here is do you need to do a lot of data processing on this computer? I doubt it if it's a samba server. All samba does is provide the SMB network transport for data to flow across. Dual CPUs won't make a dent in the speed of the traffic. Spend your money more wisely on quality fast NICs and switches. That's where you'll notice the speed difference! -Pete McDonnell
Probably the biggest single factor that will contribute to slow performance is going to be disk I/O and latency, esp. if you're going to have a lot of continuous small file operations.
I'd suggest that you get a single processor, and spend money on a good ultra 2 scsi controller. If you need data protection, run RAID 10 - it's more expensive to implement than RAID 5, but it's faster, and you wouldn't need a fancy shmancy RAID controller with an intelligent cache to keep from suffering a performance hit on writes. Ugh, call me a SCSI nazi, but i wouldn't use ATA for something more than casual use.
I didn't see mention made of how many clients you're expecting to service, but a P3 or Athlon in the 700MHz range should do pretty well. couple that with lots of RAM (1GB) and tune samba accordingly (bigger buffers = faster access). of course, faster network access would remove one more bottleneck.
Actually, I read about it in the beginning of the Oreilly book titled, "Samba". I forgot the actual pattern match, but I remember trying it and it worked (Solaris). I just checked and samba isn't in my /usr/dict/words either, but it is in the Solaris /usr/dict/words on my school network.
Keeping
You're making a file server, and by far you're biggest problem is going to be I/O bottlenecks (disk & network), NOT CPU. In fact, I can keep a 100Mbit connection fully flooded with SMB traffic with a lowly Dual PPro200 system. So the second CPU isn't necessary at all. Here are my recommendations (and I've done this before):
If the machine is doing pure Smaba serving, and you are using external PDCs, get the lowest-speed CPU you can (which will probably mean at least a 500Mhz one). It will be more than sufficient. Use the money for your disk subsystem.
If you want to do something like virus scanning, or PDC work, or even DNS serving, look into a better CPU, especially if your going to be doing Mail on the box (which is a CPU hog). In general, though, I think you'd be better off with sticking to a limited-function box and 1 CPU.
Product Plug: I like Compaq Proliants. They're very Linux-friendly, and they have the nice extras you want in a server. Here's a suggested config:
That runs $11k direct from Compaq (figure you get it cheaper from a reseller). You can knock off $2k if you use 7200RPM drives.
Look for something similar. Having a dual-capable MB is nice, just in case you decide to add crap to the machine later (or re-purpose it).
Best of Luck.
-Erik
There are always four sides to every story: your side, their side, the truth, and what really happened.
Quite simply, if this is going to be just a file server, I'd suggest going for a single cpu. IMHO, SMP is good for big badassed multithreaded apps like 3d modelling/rendering. Network servers are also heavily multithreaded, but they employ many short-lived processes whose overhead shadows the efficiency savings of SMP.. too much context switching and extra hassle. Single is simpler, and simple is fast. But what's more important here is the actual data throughput. Nic's are very important, as well as the I/O bus speed. Wide/LVD Scsi hard drive are ideal, but ATA66/100 is much cheaper and "fast enough". Now I don't know Samba's performance details, but you probably don't need a Xeon 800 to run this unless you're expecting >200 simultaneous requests. Even at 100mbps, a P2-450 with a decent amount of ram should do fine. One thing you should consider (if the guys in charge aren't Intel whores) is the AMD Athlon Thunderbird if you want to get away with it for cheap. Compared to P3's, I find they run just as fine and fast, and price wise it's an obvious winner, which would leave you with more cash left to spend on the truly critical elements : NIC's and hard drives.
-Billco, Fnarg.com
Does anyone know how samba was named?
/usr/dict/words
Give up?
He used:
grep s*m*b*
The coolest word in the resulting list was samba.
First Post?
Keeping
Single CPU?
Program will not execute!
Takes two to samba!
------
------
You are in a twisty little maze of open source licenses, all different.