3

I have a .Net application on my IIS7 server it was working fine until I had to move it to another server.

I moved the exact same code to the new server and I noticed that after some hours the website stopped responding to remote requests but if I did remote desktop to the server it responded to the request done to localhost. If I stop the website and the application pool it started working fine again.

I was able to track the problem to hundreds of requests left in CLOSE_WAIT state to the http port that are never closed (I waited a few hours and they remain the same).

Any ideias?

Improve this question
1
  • Did you ever find a solution?
    – Shiraz Bhaiji
    May 23, 2011 at 21:13

2 Answers 2

Reset to default
5

What is your version of http.sys? You may want to try the following update:

Increased latency occurs on an HTTP connection to a computer that is running Windows Vista, Windows 7, Windows Server 2008 or Windows Server 2008 R2 if the connection is through a load balancer
http://support.microsoft.com/kb/2634328

You should also confirm the value for TCP KeepAliveTime. By default, this is set to two hours. It's generally a good idea to lower this, especially for Internet facing web servers. Five minutes works well in many cases, although you may want to set this to be the same as your Session State timeout (20 minutes by default) so that your web developers won't hate you. To set the value to 20 minutes, use the hex dword value 0x00124F80: 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]  
"KeepAliveTime"=dword:00124F80

KeepAliveTime
Key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
Value Type: REG_DWORD—time in milliseconds
Valid Range: 1–0xFFFFFFFE
Default: 7,200,000 (two hours)
Description: This value controls how often TCP attempts to verify that an idle connection is still intact by sending a keep-alive packet. If the remote system is still reachable and functioning, it acknowledges the keep-alive transmission. Keep-alive packets are not sent by default. This feature may be enabled on a connection by an application.

Another potential suspect is the advanced TCP/IP features of Windows. These features can introduce subtle and difficult-to-diagnose issues, and the drivers have to be rock solid. Since most HP and Dell servers have Broadcom chips, and Broadcom is known for defective drivers with regards to these features, this is something worth considering. I personally disable these features unless I can demonstrate a measurable benefit for having them enabled. Here are the commands to enter at an elevated command prompt that will disable the features: 

netsh interface tcp show global  
netsh interface tcp set global autotuninglevel = disabled  
netsh interface tcp set global rss = disabled  
netsh interface tcp set global chimney = disabled  
netsh interface tcp set global netdma = disabled
Improve this answer
1
  • +1 The first part of the post explains exactly what happens in our environment. Thanx!
    – Benny Skogberg
    Jan 17, 2013 at 14:09
1

Check out the article may help you understand and troubleshoot the issue. I will also check for NIC driver on the server and update it to the latest.

Improve this answer
1
  • I already looked into the MaxUserPort and TcpTimedWaitDelay settings, but I didn't messed with those on the other server. The TcpTimedWaitDelay default value is 240 seconds but the connection remains in CLOSE_WAIT state for hours instead of been closed after 4min.
    – rjlopes
    Nov 11, 2010 at 15:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .