[Samba] max concurrent CIFS connections

[John H Terpstra]

On Wednesday 07 September 2005 16:18, Gerald (Jerry) Carter wrote:
> Jeremy Allison wrote:
> | On Wed, Sep 07, 2005 at 09:22:31PM +0200, Pseudomizer wrote:
> |>I need some help please. I have been told from an administrator that
> |> Samba does only support up to 3.000 concurrent CIFS connections and each
> |> connections reserve 5MB of memory.
> |
> | This is incorrect and way too high. It depends on how active each
> | connection is. On the HP PSA (Print Server Appliance) I believe it's
> | a much smaller number (I'm sure Jerry can give more accurate figures).
> | Of course that's for printing only. Depends what the users are doing.
>
> My rule of thumb is 2Mb per smbd.  With that man connections
> I'd go for a maybe an 8 way SMP box?  But to be honest, I've
> never done a server that lareg in production myself.  And I
> don't sysadmin anymore as a general rule.

Samba does not scale linearly without bounds. Nothing does!

The real bottle-neck needs to be identified. 

In a site that has heavy network usage, 30-40 concurrent users (all writing to 
disk at the same time) can choke up a server in an amazing way. In this 
situation, adding memory and/or CPUs achieves very little.

Look at it this way:

If the disk I/O architecture is provided by a controller that permits a 
sustained write rate of 300 Mbytes/sec (an amazingly fast RAID controller 
that can nearly saturate a whole PCI-X 133MHz 64-bit bus), the I/O limit is 
easily reached with 3 gigabit network cards that are appropriately 
configured. Anything more than 4 CPUs will hardly help over-all performance. 
From past benchmarking work, as well as from practical field experience, the 
benefit of adding memory under such load conditions in excess of 4GB is 
marginal to say the least.

On the other hand, if over-all network traffic is light, adding memory and 
CPU's will make all clients more responsive. But adding memory and/or CPUs 
does nothing to eliminate a disk I/O limitation.

My rule of thumb is 3.5 MBytes per concurrently writing Windows client, plus 
about 2 MB per additional client. This means that active clients will be 
served from physical memoery and passive clients will most likely be in swap.

- John T.