Ranjan Banerji

Very often I hear people make comments like "I have no idea but my servers are running really slow."  A common cause for this magical slow performance is a highly fragmented drive.  High levels of fragmentation will result in excessive disk I/O which will impact the performance of your servers.

A few years ago we were experiencing very slow query responses from an Oracle server.  The DBA laughed at me when I said check the drives.  Eventually when we checked sure enough the drives were extremely fragmented.  Once defragged (if I may use the term) the problems vanished.

Today I happened to be diagnosing why one of our servers running SharePoint and SQL Server was behaving so poorly.  A simple select count(*) from AuditData was taking over 2 minutes to return data.  Granted that the table had 13 million records. I wrote a script to delete records from this table using the SharePoint API and the code just sat there chugging for 4 hours at the end of which I had to terminate it.  A casual glance showed that this appeared to be a problem triggered by poor I/O.  When I checked the drives this is what I found.

That much red is just not good.  So before you get down to lengthy discussions about query optimizations and table indexes please stop and make sure your server is not screaming for help.

Do a search for this error and you will get plenty of hits.  What's interesting is that you will also get plenty of solutions to the problem.  Why?  Because the error can occur due to various reasons.  Well here is yet another solution because I guess there is yet another reason.

While working on a SharePoint 2007 Content Deployment we noticed that the process would fail if we had a cab file greater than about 16MB.  The failure would occur when the source machine would attempt to move the cab file (greater than 16 MB) to the destination via an HTTPWebRequest.

In the process of debugging this problem we noticed that some source machines succeeded and some failed to send the cab file.  So what was causing this problem, why was one set of machines giving us this error and another not?

After much debugging and then some help from Microsoft we tried turning off a new feature from Microsoft, i.e., The Microsoft Windows Server 2003 Scalable Networking Pack.  Amongst the features that this pack provides is the TCP Chimney Offload.

The TCP Chimney Offload will offload TCP/IP processing to your network adapter if the network adapter is capable of handling it.  Almost like handing over graphic processing to your video card and audio processing to your sound card.  MSDN documentation, however, says:

TCP Chimney offload and NetDMA will not work with the following features:

• Windows Firewall
• Internet Protocol security (IPsec)
• Internet Protocol Network Address Translation (IPNAT)
• Third-party firewalls
• NDIS 5.1 intermediate drivers

If any one of these features is turned on, TCP Chimney offload and NetDMA will not work regardless of the registry settings. (http://support.microsoft.com/kb/912222)

So just what does "TCP Chimney Offload will not work mean"?  Does it mean the offload to the network adapter will not occur or does it mean that its behavior is now undefined and that one may experience errors?  I don't know.

So on the servers where we were getting the error we set the following registry keys to 0, i.e., turning off the network pack features.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
EnableTCPChimney = 0  (DWORD)
EnableRSS = 0  (DWORD)
EnableTCPA = 0  (DWORD)

The "The underlying connection was closed: An unexpected error occurred on a receive" error vanished.  So add the TCP Chimney to the list of settings you should check and change when you get this error.