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?

Improve this question

3 Answers 3

Reset to default
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?

Improve this answer
4
  • 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. Commented Oct 6, 2010 at 6: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. Commented Oct 6, 2010 at 7: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. Commented Oct 6, 2010 at 8: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. Commented Oct 6, 2010 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.

Improve this answer
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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.