Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
What type of networking is in place? gigabit? 100megabit? Are you copying files across a LAN or a WAN/VPN? Do you have a Windows domain or a Windows workgroup? I've seen a Workgroup cause slowdowns like that. Can you FTP files faster than network share? SMB is typically regarded as a protocal that isn't very efficient over other protocols. –  Nate Nov 16 '10 at 16:31
    
@Nate Bross - 100meg, LAN, domain. –  Nate Nov 16 '10 at 16:32
2  
All directory listings take minutes, or listings of directories containing thousands of files take minutes? –  Skyhawk Nov 16 '10 at 16:36
    
@Miles Erickson - All listings can take minutes. Occasionally it'll be very brisk, but frequently trying to access network shares hangs explorer for minutes. –  Nate Nov 16 '10 at 16:39
2  
The IT manager is not very technical? Is it just me or does anyone else see a problem there ? –  Alan B Mar 15 '12 at 10:23
show 5 more comments

5 Answers 5

up vote 13 down vote accepted

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.

share|improve this answer
4  
After talking with our sysadmin, he did a test where he took down the antivirus, and the speed was blazing. Good suggestion! –  Nate Nov 16 '10 at 17:33
1  
+1 for DNS. DNS misconfigurations that lead to timeouts will have a huge impact on performance. –  duffbeer703 Nov 16 '10 at 17:48
add comment

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.

share|improve this answer
1  
+1 - The original SMB protocol (not SMBv2) sucks like a Hoover over high-latency links. With typical LAN latencies (single digit milliseconds or less) it does just fine. If the OP isn't tracking traffic and errors on switch ports this would be a good time to start. My gut says that a duplex mismatch is somewhere in this problem. –  Evan Anderson Nov 16 '10 at 17:04
1  
@evan, my gut says it's a seven-yearold single-disk dual-core 1GB server with a single 100Mb NIC ;) –  Chopper3 Nov 16 '10 at 17:07
    
Distinctly possible, though even a box like that shouldn't take minutes to return directory listings under most circumstances. –  Evan Anderson Nov 16 '10 at 17:14
    
@evan, could be a corrupt file system I guess... @nate, could you test your network by sharing a directory on one machine browsing it from another? –  Chopper3 Nov 16 '10 at 17:22
    
It may be the port the server itself is plugged into. Watching that port's error rates (late collision errors being a great indicator of duplex mismatch) and testing other types of traffic to/from that server (the "WSTTCP" utility works well for measuring raw NIC / driver TCP throughput on Windows) are probably both goods idea. Basic perf monitoring on the affected server is also a good idea-- watching CPU, RAM, network, and I/O utilization. –  Evan Anderson Nov 16 '10 at 17:44
add comment

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?
share|improve this answer
add comment

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.

share|improve this answer
1  
Well, that's what I'm asking - that are the statistics I need to be collecting? How do I go about collecting them? –  Nate Nov 16 '10 at 16:34
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.