TIME_WAIT

[nagendra_3]

Hi ,
Can any one tell me how to kill the TIME_WAIT connections on HP-UX 11.0.
I read some where that the performance goes down if the time_wait are numerous.

I am running a netscape web-server on HP-UX 11

Command used:netstat -a

Cheers,
Nag
Happy Halloween :-:
|

[harry d brown jr]

Sorry, but can't manage your socket connections like processes. It's up to the applications to fix this (netscape). You can change time to live or something of that such in netscape.


live free or die
harry

[Roger Baptiste · Accepted solution]

Hi,

to set time_wait on 11.00
do -
ndd -get /dev/tcp tcp_time_wait_interval

-> this shows your current setting.

To change it
ndd -set /dev/tcp/tcp_time_wait_interval (in seconds)

to make it permanent
change the setting in
/etc/rc.config.d/nddconf

If you want to disconnect
any existing TIME_WAIT sessions:
ndd -get /dev/tcp tcp_status >outfile
check the outfile for the
remote Ip' connections you
want to be disconnected.
Not the first column (TCP)
then, do
ndd -set /dev/tcp tcp_discon 0xfirstcolumn.

(Make sure of the connection
before you do this!).

-raj

[nagendra_3]

0fd823e8 0cc.034.176.210 f6f8bdfc f6f8bdfc 00000000 00000000 f6f76f54 f6f76f54 00000000 -N/A- -N/A- [50,e383] TIME_WAIT*
(3990)

This is the line form the output file ,

but however if i perform this command, it give me ndd -set /dev/tcp tcp_discon 0cc.034.176.210
"operation failed, Invalid argument"

Raj any comments where i have done a mistake,
Thank you for your help

[harry d brown jr]

Thanks RajMan, I was learnt today.


nagendra,

You used the second column, try the first column:

ndd -set /dev/tcp tcp_discon 0fd823e8

[Sanjay_6]

Hi Nagendra,

Have a look at these two threads. They might help.

http://us-support.external.hp.com/cki/bin/doc.pl/sid=8388d5851548343cd1/screen=ckiDisplayDocument?docId=200000042082709

http://us-support.external.hp.com/cki/bin/doc.pl/sid=8388d5851548343cd1/screen=ckiDisplayDocument?docId=200000056429107

hope it helps.

thanks

[rick jones]

hp-xu 11 should do quite well with very large numbers of TIME_WAIT connections. one thing you might consider is tweaking tcphashsz to increase the size of the hash tables.

i would be very cautious about messing with tcp_time_wait_interval. TIME_WAIT is in TCP for a specifici purpose - part of its protection against data corruption.

[Christopher Caldwell]

Rick,

Care to give any advice on tuning tcphashsz ;-):

-- tcphashsz

The size of the hash table for TCP connections is determined by the
kernel parameter tcphashsz. This kernel parameter should only be
modified under the direction of Hewlett-Packard.

[rick jones]

OK, I guess I typed right into that one didn't I :)

I'm surprised the wording is as strong as it is. Tpchashsz is something we've been tuning on most of our SPECweb9X submittals with HP-UX 11 for years and years now.

I guess some of it stems from ifyou make tcphashsz too big your kernel might not boot :)

Basically, tcphashsz controls the sizes of a number of internal TCP hash tables.

If the cut and paste works, what follows is a descrpition. I thought it was online at www.spec.org someplace as part of a SPECweb submittal but could not find it.

There are seven dynamically allocated hash lists in TCP and IP. The sizes
of these lists are controlled by the HP/UX configuration variable
tcphashsz. Since this single variable controls the size of multiple
lists, it is treated as a relative scale factor, rather than as the
actual size of any specific list. The relative sizes of the individual
lists are fixed. The absolute sizes are determined by the product of
the scale factor and the relative size.

The seven hash lists are:

ipc_tcp_fanout IP's list of all established TCP connections.

ipc_tcp_listeners IP's list of all TCP listeners.

ipc_udp_fanout IP's list of all bound UDP streams.

tcp_port_hash_arr All TCP's by local port.

tcp_listener_hash_arr All TCP listeners by port.

tcp_establshd_hash_arr All established TCP connections.

tcp_lock_list TCP's distributed lock list.

When allocating the above hash lists, the value of the HP/UX configuration
variable tcphashsz is first rounded down to the next lowest power of two.
It is then bounded on the low side at 64 and on the high side at 64K.
If tcphashsz is specified as zero, a default value of 2048 is used.
If we use 'A' to indicate the value of the resulting scale factor, the
following table lists the actual sizes of the allocation, in words, for
each of the seven lists:

ipc_tcp_fanout A / 2

ipc_tcp_listeners A / 4

ipc_udp_fanout A / 4

tcp_port_hash_arr A

tcp_listener_hash_arr A / 4

tcp_establshd_hash_arr A / 2

tcp_lock_list A / 16

The following table gives actual list sizes, in words, and total space
allocated, in bytes, for several example values of tcphashsz:

64 256 2048 16K 32K 64K
-----------------------------------------------------------------------
ipc_tcp_fanout 32 128 1024 8192 16K 32K

ipc_tcp_listeners 16 64 512 4096 8K 16K

ipc_udp_fanout 16 64 512 4096 8K 16K

tcp_port_hash_arr 64 256 2048 16K 32K 64K

tcp_listener_hash_arr 16 64 512 4096 8K 16K

tcp_establshd_hash_arr 32 128 1024 8192 16K 32K

tcp_lock_list 4 16 128 1024 2K 4K
-----------------------------------------------------------------------
total space (in bytes) 720 2880 23040 184320 368640 737280

I've no idea if it will format well, so I'll try to have a copy at ftp://ftp.cup.hp.com/dist/networking/briefs/tcphashsz.txt

[D. Jackson_1]

I have had these same issues with CLOSE_WAIT, here is how I clear it up:

ndd -set /dev/tcp tcp_discon_by_addr "ac1816585ba0ac184483564"

When you do a netstat -a, you get something like this :
tcp 0 0 172.24.22.42.58843 143.101.94.40.9102 TIME_WAIT
tcp 0 0 172.24.22.42.58842 143.101.94.55.9100 TIME_WAIT

You must convert the IP notation to hexadecimal format.
So 172.24.22.42.58842 is "ac18162ae5da" you must put a 0 between the first set of hexadecimal numbers (IP + Port #) and the second set of hexadecimal numbers..
The scientific desktop calculator can be used to do this or you can search www.google.com for Feel The Base, an IP to hexadecimal converter..
Hope this helps..

DCJ

[rick jones]

if there are large numbers of TCP endpoints in CLOSE_WAIT it implies that the local app has ignored the notification that the remote has closed its end of the connection. or...

If the local side is in CLOSE_WAIT, the other side is likely in FIN_WAIT_2. Given that FIN_WAIT_2 can be a perfectly valid recv-only state, CLOSE_WAIT can be a perfectly valid send-only state.

so, i would really strongly caution anyone against using that ndd kludge to sumarily nuke a TCP connection.

if the connection is in CLOSE_WAIT and the app has no concept of a send-only connection, the app is buggy and is ignoring the remote close indication. such an app REALLY needs to be fixed. the ndd junk is merely a bandaid and it will not cure the disease.

[rick jones]

there is a small, but vitally important typo in rajman's discussion of setting tcp_time_wait_interval for HP-UX 11.

the units are _milliseconds_ not seconds.

another reason the default TCP timers should be left along I supose :)

[Dave van Nierop]

Kudos Rick! Great advice ...