0

When I run netstat, I get this:

TCP    xxxx:65524    65.55.11.162:80        TIME_WAIT       0

There are 13941 of such lines in netstat at this point.

Server is running Windows 2008 & SQL Server 2008.

Task manager & process explorer don't show anything strange. Server uptime is probably couple of months.

Any ideas what could be the cause?

bh213
  • 103
  • 1
  • 4

3 Answers3

3

TIME_WAIT is a TCP state used to ensure that the connection is fully closed. Because the last packet that says "I'm done!" might possibly get dropped, TCP connections wait around for a period of time in case the other end tries to resend something before actually switching to the CLOSED state.

What it looks like is your server is rapidly opening and closing connections to 65.55.11.162's web server, faster than the delay for TIME_WAIT allows the server to close the connections and dump the sockets. Depending on the resources available to your server, this could exhaust the available sockets or memory and cause performance issues. If you're not seeing any performance problems, I'd simply keep an eye on it; the connections should expire in a few minutes. If it persists, consider investigating the source application its configuration. You can use netstat to display which process/PID owns the socket (netstat -p on my linux box, might not be the same on Windows2008).

Edit: Further investigation suggests that this is related to "Telligent Community" Is that an application you have installed on your system?

Darth Android
  • 545
  • 5
  • 12
  • Number of TIME_WAIT connections is pretty stable, so it is not decreasing, yet it is not causing problems. We don't have Telligent Community software installed, at least not that I am aware of :( And I did check PIDs of those connection - they are all 0. – bh213 Oct 06 '10 at 06:57
  • @bh213 It sounds like a piece of software pinging home every couple of seconds. Pointing my browser to that IP gives me a page saying my host isn't authorized to use Telligent Community. Try pointing a webbrowser from the server to that IP and see if it gives you something different. – Darth Android Oct 06 '10 at 07:22
  • @Darth-Android - I did try that - I get the same message as you did. Problem is that I cannot see the program doing this. I blocked that ip by using firewall but that doesn't really solve the problem. – bh213 Oct 06 '10 at 08:08
  • @bh213 Apparently orphaned `TIME_WAIT` sockets are handed off to the system to timeout. I would run a firewall on the system which can track processes trying to access `65.55.11.162` and use that to determine the process when it tries to establish the connection. If the firewall reports the "system" is trying to establish the connection and not a process, I would suspect that something has injected something into the kernel. – Darth Android Oct 06 '10 at 16:22
1

Any ideas what could be the cause?

Internet server? Ever thought about the internet? IIS is TCP based. Darth Andoid has a tehnical explanation. Spiders could be the reason.

SQL? Lots of opened / closed connections and no connection pooling.

TomTom
  • 51,649
  • 7
  • 54
  • 136
0

It turned out to be Amazon EC2 issue - sometimes host machine would report time a few years in the future causing sockets not to timeout and get cleaned. This has been fixed and is no longer an issue.

bh213
  • 103
  • 1
  • 4