Question

Locked

Why is my server slow to less than gigabit pc's?

By PaulBToms ·
I have a file server running Windows 2003 (it's also a domain controller). I just noticed today that the users are having trouble with files on that server opening/copying very slowly. A 6 meg file takes 4 minutes, 12 meg takes 7. Files from other 2003 servers copy quickly. Server has gigabit ethernet, workstations are 100. Copying to another server or my workstation, which are also gigabit, is very fast. Why would it be so slow to the regular workstations? Only thing I can think is that a week ago I realized when trying to restore from a backup that the server was plugged into the wrong switch, so I quickly switched it to the gigabit switch. The backup sped up tremendously, immediately. I don't know if the slow issue started then or not. Any ideas?

This conversation is currently closed to new comments.

5 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Answers

Collapse -

Request for Clarification

by rstreich In reply to Clarifications

Sounds like a network problem. Which switch are the workstations plugged into. Also which switch is the other server plugged into?

Rob

Collapse -

Lets get this right

by OH Smeg In reply to Why is my server slow to ...

When you connect with a Gigabit System it's fast but when you connect with a 10 T Base it's slower right?

What do you expect? a 100T base is slower than a Gigabit and you can not exceed the Speed of the Slowest Data Connection on the Network. So if you are attempting to copy to a computer with a 100 T Base Connection it can only copy at 100 T Base Speeds.

Col

Collapse -

Possible Cause: Switch Configuration

by ricojonah In reply to Why is my server slow to ...

Hello Paul. I've encountered similar problems quite a number of times in my previous occupation. In the vast majority of those cases, the most common issue turned out to be the actual switch configuration for a specific port. Depending on the switch you're using, it's not too uncommon to find that a number of ports have been explicitly configured as a 10Mbps interface. In other cases, the auto-negotiation feature can sometimes result in a duplex mismatch. Setting the switch port configuration explicitly to duplex mode (and, if necessary, to 100/1000Mbps for the speed) usually resolves this problem.

In the case that the problem you're encountering is not a switchport issue, I would suggest testing the transfer rate between your server and a client using something besides the type of file transfer you're currently using. For instance, if you're transferring the files using CIFS/SMB (i.e, a windows share), try testing a transfer of some significantly-sized files using FTP or any other available methods.

This is, of course, assuming that there aren't a number of other devices, such as routers or additional switches, standing between your server and the clients. If that's the case, then you might need to provide more information about your setup.

Best of luck to you!

Collapse -

One thing that may pick up your speed

by Alpha_Dog In reply to Why is my server slow to ...

First, get a transfer started and look at the switch. Any idiot lights telling you that not all is well? Also try to transfer between workstations. If that's slow too, your switch is bjorked. It may be a good time for that gigabit switch upgrade. If nothing jumps up at this point and says "I'm the culprit, smite me mightily!" proceed on.

After you check all the stuff posted by ricojonah, try these steps as well. In your network properties, kill all the unnecessary services, QoS, monitoring, and IPv6 support unless you are using them. It will also boot and synch up faster.

Kill all the IPv6 stuff in one fell swoop. Then shut down the network services one by one starting with the monitoring/call home to mama stuff. Before you proceed, ensure that everything still works for a few moments.

Collapse -

look at your CIFS SMB Signing

by danekan In reply to Why is my server slow to ...

First and foremost, have you eliminated all physical type problems (improper cables, cables unfurled for too long at the network jack itself, cables not ran through fluorescent light tube fields, etc)? If you hook a workstation up directly to your switch in the same position your server to server test was done using the same network patch cable, do the results still seem slow on the workstation?

I could be wrong, but I think running your domain controller as a file server for anything substantial is probably not a great practice in general. By default, Windows 2003 and on domain controllers have SMB signing required and turned on, which adds an overhead to all of that network traffic as a result. Overhead in terms of data packet size, overhead in terms of processing capacity required, etc. I've read varied estimates as to how much overhead this is, but I've read some saying 40% for larger files. It may not be your exact problem, but it's not helping probably either.

You can modify your group policy and disable the SMB signing requirements to test if there's any significant difference. In our corporate environment, Cisco, Netapp, Datalink have recommended disabling SMB signing as it is. (for a variety of reasons, but mainly because you can't really accelerate WAN traffic that's SMB signed)

Also, be aware you're running what's considered an older operating system at this point which is not using SMB2 (regular SMB in Windows Server 2003, 2008 introduced SMB2, and 2008 R2 is technically SMB 2.1). SMB2 is generally a more reliable protocol, and more efficient than it's predecessor. For many smaller bits of data to be transmitted, it is much more efficient. It's also much more reliable over potentially unstable WAN links. It has larger buffer sizes for everything. SMB2 is available in Windows Vista and on, and Windows Server 2008 on the server side. What version of Windows are you running on the workstations? Unless they're Vista+ there's no benefit to upgrading the server as XP clients will still us SMB1. But, long and short, I've seen tests where the same file transferred over a local LAN can take 20 seconds on SMB vs 5 seconds on SMB2 when all else is equal. It's really a lot of variables, though. 4 minutes for a 6 meg file is a problem way beyond this being the issue, though.
What version workstation OS?

Have you checked the workstation event logs? You don't see session any TCP limit errors or other TCP errors, do you? 'TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts' or similar? If so, you can try increasing the number of TCP sessions allowed from 10 to a higher number. (Win XP SP2 and on through Vista Sp2 have this limit, so if you're XP Sp3 or Vista SP1 for example this applies). If you're seeing this error, though, it's not abnormal at all and is actually intentional. But it does mean that Windows is delaying and slowing down the network throughput on that given machine. The intent of limiting it to 10 connections relates to the impact a virus outbreak could have, but it limits your actual work as well. Windows Server 2003 has it's own SYN-ACK protection to enable/disable, but has no half open concurrent session limit so a server shouldn't experience this problem in server-to-server transactions. There are a number of other TCP/IP stack modifications that make a server faster than a workstation though too.

Also, I would look in Performance Monitor at the data for your network card offloaded connections, packets outbound/inbound discarded/errors

Back to Networks Forum
5 total posts (Page 1 of 1)  

Related Discussions

Related Forums