SMB claimed to be "slow"

Question

Our company network (which I believe is a windows domain run on server 2008) is painfully slow. A prime example of this is copying files over SMB - listings take minutes, and copying even modestly sized files takes even longer. When approached regarding the issue, the IT manager (who, in spite of whatever other merits he might have, is a very stubborn and not a very technical person) throws his hands up, becomes very defensive and gives excuses instead of listening and attempting to work out the root cause of the problem.

Now, recognizing that the human element of this problem will take some time and effort to solve, I am left not knowing quite how to technically rebut his excuses. In this instance, he claims that SMB is the problem, and that it is a "slow" protocol. Is there any evidence for this statement (I only have anecdotal counter evidence)? What is the best way to make headway in this argument?

Answer 1

SMB might well be slower than some other file sharing protocols, and it might well be faster than some others. But that's not the important part.

Instead of making that the question/argument, can you find a way to move on from that and ask whether SMB is as fast (or as slow!) as it is supposed to be. For example, can you transfer a file using FTP between the server and a workstation that suffers from the slowness and see a marked jump in performance?

The vendor might be able to point you to reviews for the hardware, with Windows installed, that talk about file server performance.

In my experience, SMB is more than "fast enough" on my network. We're running a 10Gb network between the servers and we're very happy with file server performance using SMB and we have measured good performance jumps on the same hardware depending on whether we use the 1Gb or 10Gb NIC. SMB isn't a problem for us.

I'd certainly be looking at other things on your network - is the infrastructure outdated, is it configured optimally (e.g. server network cards all configured correctly for latest drivers, working properly at the best possible speed), are things like DNS and so-on all configured properly, is there a lot of "junk" traffic on the network causing a slowdown, is the antivirus configured in an overly paranoid manner (I've seen this cause some shocking slowdowns).

There's a lot that can cause bad file server performance and very little of it is the protocol choice.

Answer 2

Whilst there are faster protocols than SMB it's not by any means inherently slow.

It is however perhaps a little more susceptible to outside influences than other protocols, these being saturated servers, saturated segments etc.

If I were a gambling man I'd suspect that your network could do with either a redesign or some investment as many company's regular office networks haven't been upgraded to take into account the huge increase in internet and intranet traffic seen over recent years. Also there's a reasonable chance that the server/s may need replacing or rework to get the best from them.

Either way I wouldn't put too much emphasis on SMB being the direct culprit, it's more than likely to just the fall-guy for bad/old network and server kit.

Answer 3

It does have more overhead (for transfer) than things like NFS or FTP. File listing of large directories can take a while - some of this is due to SMB, some due to NTFS, some due to stupid things that the various versions of Explorer, and installed software, can do from the client end. Certain things like file-based databases (Access, PST files) should not be opened across slow (WAN) links because they don't deal well with latency.

Having said that, the operations that you describe shouldn't take a long time. Maybe the fileserver(s?) is/are underpowered. Maybe the company has some software as part of the standard install that slows things down. Maybe there's a misconfigured virus scanner. Maybe there's a virus. Maybe there's a WAN link you don't know about between you and the server.

1. Is listing files faster if you do it from a command line instead of Explorer?
2. How about copying?
3. Ping the server in question from your desktop - what's the latency?
4. Do a traceroute - how many hops are between you and the server?

Answer 4

Unfortunately Nate, we can't deal directly with PHBs. Your first line of defense here is actual metrics, as in, do comparisons between SMB transfer and NFS, for example.

Once you have actual numbers or statistics to back your arguments up, you won't need to deal with the human element as much. Statistics say "here is where the problem is, and here's the proof." That's your argument.

Answer 5

Can you narrow it down at all? Does a server-to-server transfer on the same subnet have better results? How about transfer from one client to another (\\client\c$ → \\client\d$)?

You may find something as simple as duplex mismatch.

Answer 6

I know this is old, but a very important factor to take into consideration is disk I/O. If the disk write performance is incredibly slow due to software / motherboard RAID as opposed to a hardware-based RAID card with dedicated memory.

Network load is a factor, but the best thing to do as a sysadmin is look at Resource Monitor and inspect where the bottlenecks might be originating from - inspecting the Overview tab to show overall CPU, Network, Disk I/O, Memory, etc. From this vantage, you can see if there is a culprit process or set of processes eating away at Disk I/O, or a memory leak (SQLServer.exe - SBSMonitoring instance), etc. If there is a network process using a lot of bandwidth, check that process and inspect how many and what the hosts are that are tied to that process. It could be a lot of hack attempts to RDP in on 3389. I've seen that before as the case and our solution was to remove direct RDP access and shift end remote users to VPN in.

Hope this helps!