Hardware specs for samba server

We may need to set up a dedicated linux box that NFS-mounts an Acopia
switch filesystem and then servers it up via Samba for Windows clients.
(Acopias cannot support NFS and CIFS on the same file share.)

The box would server about 30 Windows clients with heavy traffic (large
sound file processing.)

Any idea what kind of hardware (CPU number/type, RAM, etc.) would be
required to make this a robust system?

-karen

K. Bruner wrote:

> We may need to set up a dedicated linux box that NFS-mounts an Acopia
> switch filesystem and then servers it up via Samba for Windows clients.
> (Acopias cannot support NFS and CIFS on the same file share.)
>
> The box would server about 30 Windows clients with heavy traffic (large
> sound file processing.)
>
> Any idea what kind of hardware (CPU number/type, RAM, etc.) would be
> required to make this a robust system?
>
> -karen

Assuming 100kb per second download, 30 users will want 3Mb bandwidth
on the network card. Modern hard disks easily manage 7Mb. Put in some
ram to allow cacheing - say 1Gb and 30 users on a 1Ghz PC should be
a doddle. The network card is going to be the limiting thing. Use
100Mb/s card. If users are not simultaneously using the server
then unused bandwidth available for sharing.
You could mirror the server and split the users across two servers
unless of course they are all dependent on one set of real
time copies.

> We may need to set up a dedicated linux box that NFS-mounts an Acopia
> switch filesystem and then servers it up via Samba for Windows clients.
> (Acopias cannot support NFS and CIFS on the same file share.)
>
> The box would server about 30 Windows clients with heavy traffic (large
> sound file processing.)
>
> Any idea what kind of hardware (CPU number/type, RAM, etc.) would be
> required to make this a robust system?

If you really want up to 30 *simultaneous* connections with large files,
then things start to get a little beefy.

There are a lot of technical details on my reasonings, but I'll skip them
for brevity - if you really need them, ask. I just transferred a 140 MB
file from my Samba server to another machine. The server in question has
dual 1.266 GHz pentium 3 CPUs, and a gig of memory. The Samba process on
the server used, on average, very close to 10% of a single CPU.

So, extrapolating, if you wanted to handle 20 simultaneous clients working
on large files, then I'd definitely recommend a dual-CPU machine. Remember
that you're not just handling the simple CPU load of handling the Samba
processes, you're going to be handling a good number of interrupts and
context-switches on gigabit ethernet connections to be pulling/pushing data
from the Acopia to your clients. While you can easily get a full gigabit in
testing situations, actually serving out anywhere near a gigabit of useful,
processed data is fairly tough, even with a dual-CPU machine. In fact, you
shouldn't expect to ever get a full gigabit/second from the acopia, in a
network card, through the IP stack, to the Samba process, back through the
IP stack, and back out another network card, even if you do use dual CPU's.
Note that copious quantities of memory in this machine for disk cache may
reduce the load at least of pulling most commonly-used data from the Acopia,
but that depends on your data and usage model.

Also, don't forget the network: Even if your clients are only on 100 mbit
connections, you can't expect twenty clients to fight for the single 100mbit
connection to your Samba server. You'll need a gigabit connection to the
switch to which your clients connect. If that switch doesn't have a gigabit
port, then factor in the cost of a new switch.

steve

begin (E-Mail Removed) (K. Bruner) dedi ki:

> We may need to set up a dedicated linux box that NFS-mounts an Acopia
> switch filesystem and then servers it up via Samba for Windows clients.
> (Acopias cannot support NFS and CIFS on the same file share.)
>
> The box would server about 30 Windows clients with heavy traffic (large
> sound file processing.)
>
> Any idea what kind of hardware (CPU number/type, RAM, etc.) would be
> required to make this a robust system?

Most probably the Acopia server will set the ceiling of your scalability,
if you can't manage it to handle this kind of I/O load and network traffic.

You will need Gbit LAN between Linux and Acopia file server, and a Gbit to
100Mbit fan-out switch between Linux and 100Mbit/s clients.

To lessen the CPU and I/O load on Acopia and ethernet connection to it, I
suggest as much RAM as possible on Linux. Select DIMM density as if you
would go for 4G, but start with single DIMM (1G), as you can always easily
add on RAM.

As for the CPU, it would handle nfs client for Acopia access, Samba for
clients, and dual Gbit NIC for LAN traffic. As I can't precisely guess a
minimum and maximum range, I would have done it in 2 steps.

First I would have used a high powered lay-around machine temporarily, to
monitor CPU consumption for a given load, and then I would have
extrapolated this data for full load. Failing that, I would have gone for
a uniprocessor Athlon motherboard and use a run-of-the-mill Athlon (e.g.
2400+) to do the measurements. If it fits you then just continue using it.
If it doesn't, well, you have done your measurements for precise CPU
capacity planning, and you can always use that uni-processor Athlon 2400
mobo/CPU pair in some future machine you would need to build. Failing
that, I would have gone for dual-Athlon64 motherboard, install a
moderately powered Athlon64 CPU (e.g. 2800 or 3000), and cross my fingers
that actual CPU power needed wouldn't exceed dual Athlon64.

But, in any case, I would have used an Athlon.

--
Abdullah | aramazan@ |
Ramazanoglu | myrealbox |
________________| D.0.T cöm |__

begin "Steve Wolfe" <(E-Mail Removed)> dedi ki:

> There are a lot of technical details on my reasonings, but I'll skip them
> for brevity - if you really need them, ask. I just transferred a 140 MB
> file from my Samba server to another machine. The server in question has
> dual 1.266 GHz pentium 3 CPUs, and a gig of memory. The Samba process on
> the server used, on average, very close to 10% of a single CPU.

Hmm, assuming you've been able to saturate a 100Mbit LAN, it would take
100% of 1266MHz PIII to saturate a Gbit LAN, theoretically. Considering
the differences in your setup and OP's, then my CPU suggestions in other
post need a serious correction: Instead of a dual amd64 mobo, any run of
the mill Athlon should handle the load.

> So, extrapolating, if you wanted to handle 20 simultaneous clients working
> on large files, then I'd definitely recommend a dual-CPU machine. Remember

But (Gbit) LAN speed wouldn't allow for linear extrapolation. Though it
may be possible to scale higher with the help of gobs of RAM on Linux
box, which should lessen the load on inter-server traffic due to caching,
and multiple Gbit channels between Linux and clients.

--
Abdullah | aramazan@ |
Ramazanoglu | myrealbox |
________________| D.0.T cöm |__

> > So, extrapolating, if you wanted to handle 20 simultaneous clients
working
> > on large files, then I'd definitely recommend a dual-CPU machine.
Remember

> But (Gbit) LAN speed wouldn't allow for linear extrapolation. Though it
> may be possible to scale higher with the help of gobs of RAM on Linux
> box, which should lessen the load on inter-server traffic due to caching,
> and multiple Gbit channels between Linux and clients.

You can assume a fairly linear extrapolation for Samba's CPU usage: But
if you're trying to fill a gbit line, it's a bit *worse* than linear,
because of the rate of interrupts.

I watched the dual P3/1.266 machine today while it was under light load
(2 or 3 simultaneous users), and it wasn't uncommon to see a single Samba
process eating up 25% to 40% of a CPU. If you really want to get a large
number of simultaneous connections and fill a gbit line, I really wouldn't
try doing it with a single-CPU machine.

steve

On a somewhat-unrelated note, we have the dual P3/1.266 machine as the
Samba server, and a dual P3/866 machine that makes backups of the Samba
server and a few other development machines. The backup server does an
rsync to maintain a mirror of the data, then tar/gzips it up for
point-in-time snapshots. ("I deleted this file four days ago!") I just
ordered an Athlon64 3000+ to replace the 866's. You'd think that the 866's
would be overkill, but here's the problem: It's backing up so much data
that the 866 MHz chip simply cannot gzip a full backup in a 24-hour period!
; )

(I know, I could simply tar the file without gzipping it, but the
machine's only got a *measly* 2.4 terabytes, and without compression, we
wouldn't be able to keep the snapshots.)

steve

Abdullah Ramazanoglu <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> begin (E-Mail Removed) (K. Bruner) dedi ki:
>
> > We may need to set up a dedicated linux box that NFS-mounts an Acopia
> > switch filesystem and then servers it up via Samba for Windows clients.
> > (Acopias cannot support NFS and CIFS on the same file share.)
>.....I would have gone for dual-Athlon64 motherboard, install a
> moderately powered Athlon64 CPU (e.g. 2800 or 3000), and cross my fingers
> that actual CPU power needed wouldn't exceed dual Athlon64.
>
> But, in any case, I would have used an Athlon.

Me too.
But I'd also consider having two separate samba servers, with half the
clients connecting to each. I agree with all the gb network stuff,
and if it were possible to split the clients onto two switches, one
per samba server, it would give you a lot more flexibility and reduce
the conflicts a lot.

I've handled a lot of huge files for seismic processing, and had
significant problems with mixing NFS implimentations from different
operating systems. It takes a bit of experimentation to get
everything working right, sometimes. You do right to go for Samba, as
MS services for Unix just failed to cope at all.

begin (E-Mail Removed) (Robert E A Harvey) dedi ki:
> Abdullah Ramazanoglu <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>> begin (E-Mail Removed) (K. Bruner) dedi ki:
>>
>>.....I would have gone for dual-Athlon64 motherboard, install a
>> moderately powered Athlon64 CPU (e.g. 2800 or 3000), and cross my fingers
>> that actual CPU power needed wouldn't exceed dual Athlon64.
>>
>> But, in any case, I would have used an Athlon.
>
> Me too.
> But I'd also consider having two separate samba servers, with half the
> clients connecting to each.

Yeah, that simple. I don't know how I failed to consider that, but I
guess sometimes one doesn't see a most obvious thing out in the open, and
start searching it under the sofa...

Instead of clogged ethernet channels and overly priced dual CPU stuff, it
makes definitely sense to start with a uniprocessor AMD-64 and add on
machines, instead of CPUs, if/when needed.

> I agree with all the gb network stuff, and if it were possible to split
> the clients onto two switches, one per samba server, it would give you a
> lot more flexibility and reduce the conflicts a lot.

It could also be possible to divide the load on volume basis or perhaps
balance the load via LVS.

--8<--
--
Abdullah | aramazan@ |
Ramazanoglu | myrealbox |
________________| D.0.T cöm |__

Steve Wolfe wrote:

> I just transferred a 140 MB
> file from my Samba server to another machine. The server in question has
> dual 1.266 GHz pentium 3 CPUs, and a gig of memory. The Samba process on
> the server used, on average, very close to 10% of a single CPU.

Then you have incredibly rubbish disk performance.

I can fill a 100mbit pipe with Samba traffic *continuously* from a
single Celeron 533 MHz box, taking about 40% CPU overall.
The only bottleneck for Samba that I've ever seen on anything over 500
MHz is the disk I/O speed.

> So, extrapolating, if you wanted to handle 20 simultaneous clients working
> on large files, then I'd definitely recommend a dual-CPU machine.

I'd go for 4GB of RAM, myself.
Take the disk I/O out of the equation.

> Remember
> that you're not just handling the simple CPU load of handling the Samba
> processes, you're going to be handling a good number of interrupts and
> context-switches on gigabit ethernet connections to be pulling/pushing data
> from the Acopia to your clients. While you can easily get a full gigabit in
> testing situations, actually serving out anywhere near a gigabit of useful,
> processed data is fairly tough, even with a dual-CPU machine. In fact, you
> shouldn't expect to ever get a full gigabit/second from the acopia,

That is not under his control, obviously.

> in a
> network card, through the IP stack, to the Samba process, back through the
> IP stack, and back out another network card, even if you do use dual CPU's.

Easily.


--
J

All your bits are belong to us - again.