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."

Comments

Re:samba name?

[Tony Shepps]

Impossible.

Firstly, that's not proper syntax. It would have had to have been either:

grep "s.m.b." /usr/dict/words

...which gets me...

consumable
presumably
resumable
somebody

Or maybe it was

grep "^s.*m.*b.*" /usr/dict/words

...which gets me...

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.
--

Re:Single cpu, monster hardware

[X]

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:

1. Fewer context switches. If you have a LOT of processes running, it's amazing how much CPU time gets lost to context switches. SMP helps reduce this overhead because it reduces the number of processes per CPU. Of course, it also increases context switch time, so you have to balance it.
2. Better interrupt handling. On most PC's, the interrupt hardware sucks. This is important for a network server because it usually gets hit by quite a bit of interrupts between disk and network cards. SMP systems tend to have APIC and other fancy interrupt handling mechanisms, although some of the newer single CPU boards are now incorporating these features.
3. Better I/O subsystems. In general, SMP motherboards tend to have better I/O subsystems, because with multiple CPU's it's much easier to stress the I/O subsystem. Things like 64-bit 66MHz PCI can really help a serer. Of course, if you get a really fancy single CPU system this is less of a factor.
4. Faster authentication. Authentication can actually be the bulk of the latency people encounter when accessing data from an SMB server. If you are using the SMB box as a domain controller then you are going to have a lot of CPU performance lost to authentication. Being a domain controller is heavy duty work (so much so that Microsoft suggests secondary domain controllers for large networks). This can really slow things down. Of course, the best solution is to have a seperate box dedicated to doing authentiction, but if not, this is one area that will take advantage of CPU performance.

Your biggest performance improvements will probably come from doing a few basic things right:

• Get a(some) very nice NIC(s). For maximum performance get something which will handle the IP stack on board.
• Go with a fancy disk subsystem. If you really need performance go with Ultra-160 SCSI, preferably hooked up to 64-bit 66MHz PCI. Think about RAID, think about multiple controllers.
• RAM. Lots of it and as fast as possible. This will increase the disk cache and how many processes/sockets you can have going at once.

Hmmm...

[BJH]

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.

You're not calculating all that data!

[chargen]

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

Re:Single cpu, monster hardware

[Omega996]

my experience with samba has been that disk i/o is more important than cpu horsepower.

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.

Re:samba name?

[grammar nazi]

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.

I/O, I/O, it's off to work I go...

[trims]

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):

• Use Seperate NT Boxes for Domain Controllers. If you're going to be serving Windows clients, it's alot easier to set up 3-4 cheap PCs (say $1k each (new)) to be dedicated BDC/PDCs. Since you can locate the DCs near (in network terms) the clients, you're going to get much better authorization and login response times than using the Samba server as authorizer.
• As a correllary to the above, put a dedicated pipe from the Samba box to the PDC - slap in an extra network card for each box, and give the samba server a dedicated route to the PDC - this will help speed things up quite a bit.
• Disk Speed is Everything - As another poster suggested, use a hardware Raid 10 solution. Raid 5 will be ok, but 10 will be much faster. In either case, USE SCSI. Don't even think about IDE. Get 10,000rpm disks if you can, but more 7200RPM disks is better than fewer 10k disks. Go for a minimum of Ultra2 LVD drives, or Ultra3 if you can.
• Use multiple NICs - Your other bottleneck will be the network. At the minimum, use a different NIC for each major network segment. If you can, use a switch that allows for NIC bonding (like Cisco 2900s), so you can aggregate the NICs (it's alot cheaper to get 4 100Mbit NICs bonded into a 400Mbit channel than to try for Gigabit Ethernet).
• Get lots of RAM - this will be used for disk caching, which speeds things up alot. A minimum of 512MB is acceptible, and 1GB might be nice, depending on what else is going on.

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:

• Compaq Proliant ML370 w/ 600Mhz CPU
• 512MB RAM
• Integrated 2-channel SmartArray Ultra2 LVD raid controller
• 2 100Mbit NIC cards
• 6 Hot-swap Ultra2 LVD 10k RPM 18.2GB hard drives
• Redundant power supply

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

Single cpu, monster hardware

[billcopc]

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.

samba name?

[grammar nazi]

Does anyone know how samba was named?

Give up?
He used:
grep s*m*b* /usr/dict/words

The coolest word in the resulting list was samba.

First Post?

Haiku

[YASD]

Single CPU?
Program will not execute!
Takes two to samba!

------