TIME_WAIT connections

[Daniel_74]

I have two HP-UX 11.00 servers. In order to be simple, hotsnames for them are:

ota02
ota03

I have in each one a http client. Besides, in ota03 I have a http server.

I can see (netstat -na0 a lot of TIME_WAIT connections.

What could be the problem?
How can I kill such connections?

Thanks in advance
Daniel

[Michael Steele_2]

This thread does an excellent job covering the process:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xe1b14e49c5cdd5118ff40090279cd0f9,00.html

[Kevin Wright]

use ndd to lower your time_wait_interval 60000, the default, is too high.
ndd -get /dev/tcp tcp_time_wait_interval
60000

ndd -set /dev/tcp tcp_time_wait_interval 20000

you can put this into /etc/rc.config.d/nddconf to survive reboots.

[rick jones]

Likely as not, there is nothing wrong. TIME_WAIT is perfectly normal for a TCP connection - and lots of them is quite normal when you are running http.

The only reason to shorten the tcp_time_wait_interval would be _in the lab_ when you are trying to do http load testing and have not got a properly written http load generator. Such an improperly written load generator will allow the system to select the client port number and so may run into issues with reuse of a TCP connection name (local/remote IP, local/remote port) within the TIME_WAIT interval.

The "proper" way to deal with this is to make sure that the load generator makes an explicit call to bind() with port numbers in the range of say 5000 to 65535. This will then allow that one load generating IP to generate as many as (maxclientport-minclientport)/time_wait_interval - (65535-5000)/60 or 1000 connections per second.

If the load generator relies on the default anonymous/ephemeral port range (what the stack uses when you don't call bind()) then the rate cap per load generating IP would be (65535-49152)/60 or ~270 connectoins per second.

If you cannot get the load generator coded correctly, then the first workaround would be to change the values of tcp_smallest_anon_port rather than change the tcp_time_wait_interval.

And under no circumstances should one start using that ndd kludge to start terminating connections...certainly, not in a situation like this. HP-UX 11 does quite well with hundreds of thousands of TIME_WAIT connections.