50+ connections from Zabbix?

[Villain]

Is there a reason that my Zabbix server is making 50+ connections to each of my machines and not releasing them after getting the data?

I just looked at one of our Windows 2000 servers, and it had approximately 50 connections that were still in TIME_WAIT (using netstat -a to find this). We just looked at one of our linux boxes and it has 202 open connections.

Why would it have this many and not release them?

[Alexei]

TIME_WAIT is a normal state of a TCP socket. The state does not indicate that the connection is open, it is already closed.

[Villain]

so then what would be the purpose of putting them in a TIME_WAIT state and not just closing them and going back to a Listening state instead?

[peter_field]

References

I must admit I find this very very annoying also, I am sure that Alexei could get around this somehow, but as always it comes down to effort vs reward. Alexei, can you use this technique to solve this:

http://mail.python.org/pipermail/python-bugs-list/2005-February/027757.html

http://www.fastcgi.com/archives/fastcgi-developers/2003-July/002790.html

Villain, I could try to explain this, but I'm not going to reinvent the wheel, here are some references that explain how and why this works. There is a registry key you can change that will lower the timeout, this may help.

Explanations:

http://codebetter.com/blogs/sahil.malik/archive/2004/06/09/15893.aspx

How to control the timeout:

http://support.microsoft.com/kb/314053

http://publib.boulder.ibm.com/infocenter/cicsts/v2r2/topic/com.ibm.cicstg600.doc/ccllal0264.htm

The following is from:

http://support.microsoft.com/kb/314053

TcpTimedWaitDelay
Key: Tcpip\Parameters
Value Type: REG_DWORD - Time in seconds
Valid Range: 30-300 (decimal)
Default: 0x78 (120 decimal)
Description: This parameter determines the time that a connection stays in the TIME_WAIT state when it is closing. As long as a connection is in the TIME_WAIT state, the socket pair cannot be re-used. This is also known as the "2MSL" state. According to RFC793, the value should be two times the maximum segment lifetime on the network. See RFC793 for more information.

Note In Microsoft Windows 2000, the default value is 240 seconds. For Windows XP and Microsoft Windows Server 2003, the default was changed to 120 seconds for the IPv4 stack to increase performance. The default value for the IPv6 stack is 240 seconds.

[Alexei]

I used the optional SO_NOLINGER option before in agent and server code. It is dangerous because it destroys all socket related data immediately after socket close causing loss of data on recipient side.

I think that minimizing number of connection is the most correct way of solving this "issue". The agent and the server, both, should be smart enough to collect, send and process not only single values, but also bulk data.

[peter_field]

Your right

Yes, reducing the number of connections would be the right way to go, but I imagine this would be somewhat more difficult to implement.

Is this something you are looking at implementing?? It would be nice. Particularly on Windows where grep doesn't exist, and your stuck with the much more limited find command for parsing the netstat output.