Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
AIX close_wait
- Thread starter greatlax
- Start date
Nothing that I have read about this problem is good. Here is an RFC reference that indicates that this is a TCP bug, but doesn't have any recommendations for fixing it.
But I did find a single reference to changing the TcpTimedWaitDelay value in IIS. Apparently the default timeout for a close_wait state is 4 minutes.
From Experts-Exchange:
You should change the registry as folows:
1) goto the folowing key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters
2) Add a Value:
Value Name:
TcpTimedWaitDelay
Data Type:
REG_DWORD
Value:
30-300 (decimal) - time in seconds
The default is 240 if the value is nor present.. which is quite a long time to keep a socket open on pending for closure.
Any Web Server on a Win32 platform should change this Value because sooner or later all the sockets would be in that state and no new connections untill a socket wuld go out of TIME_WAIT state.
--------------------------------------
Now, since this is a windows fix, it doesn't directly apply, but there is probably a similar setting in WebLogic that will allow you to "fix" the problem. If the first document is correct, and this state occurs when users click on another link before the page has fully downloaded, you will never be able to eliminate the problem. But setting the timer down to some more reasonable value, like 30 seconds, should help keep you from exhausting your resources.
pansophic
But I did find a single reference to changing the TcpTimedWaitDelay value in IIS. Apparently the default timeout for a close_wait state is 4 minutes.
From Experts-Exchange:
You should change the registry as folows:
1) goto the folowing key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters
2) Add a Value:
Value Name:
TcpTimedWaitDelay
Data Type:
REG_DWORD
Value:
30-300 (decimal) - time in seconds
The default is 240 if the value is nor present.. which is quite a long time to keep a socket open on pending for closure.
Any Web Server on a Win32 platform should change this Value because sooner or later all the sockets would be in that state and no new connections untill a socket wuld go out of TIME_WAIT state.
--------------------------------------
Now, since this is a windows fix, it doesn't directly apply, but there is probably a similar setting in WebLogic that will allow you to "fix" the problem. If the first document is correct, and this state occurs when users click on another link before the page has fully downloaded, you will never be able to eliminate the problem. But setting the timer down to some more reasonable value, like 30 seconds, should help keep you from exhausting your resources.
pansophic
JasonDeckard
Programmer
This is not an error - close_wait is a normal stage in a socket's life cycle.
JasonDeckard
Programmer
I guess I should elaborate:
CLOSE_WAIT is the state of a socket that has acknowledged receiving a FIN (a close request) from the remote host, but is still waiting on the last ACK from the remote.
A normal session close is a lot like the TCP handshake:
After Host B sends the FIN/ACK, and until it receives the ACK from Host A, it will be in CLOSE_WAIT.
Windows 9x systems (not sure about the other win versions) are notorious for not sending that last ACK. The socket will eventually close on its own.
CLOSE_WAIT is the state of a socket that has acknowledged receiving a FIN (a close request) from the remote host, but is still waiting on the last ACK from the remote.
A normal session close is a lot like the TCP handshake:
Code:
Host A Host B
FIN --->
<--- FIN/ACK
ACK --->After Host B sends the FIN/ACK, and until it receives the ACK from Host A, it will be in CLOSE_WAIT.
Windows 9x systems (not sure about the other win versions) are notorious for not sending that last ACK. The socket will eventually close on its own.
A year ago or so, a client of mine was running Weblogic on Solaris, and had similiar problems with CLOSE_WAIT. If I remember correctly, they received a fix to upgrade Weblogic which apparently had something to do with the terminations of TCP-sessions. Before they solved the problem, they had a script running which would restart the process after 500 or more CLOSE_WAIT entries...
- Thread starter
- #6
As I said, it's a year or so ago, and currently I don't have any business with the client...
The script was basicaly a 'netstat -na | grep 'CLOSE_WAIT' | wc -l'. If the results were above a certain number (say, 500) the Weblogic process would be restarted. This would forcefully eliminate the tcp sessions in the CLOSE_WAIT state, since the process owning the socket would restart (weblogic in this case). It would also terminate current ongoing sessions...
Login to and search for CLOSE_WAIT or such. If I remeber correctly they upgraded to 6.something, but I might be all wrong.
~Mike
The script was basicaly a 'netstat -na | grep 'CLOSE_WAIT' | wc -l'. If the results were above a certain number (say, 500) the Weblogic process would be restarted. This would forcefully eliminate the tcp sessions in the CLOSE_WAIT state, since the process owning the socket would restart (weblogic in this case). It would also terminate current ongoing sessions...
Login to and search for CLOSE_WAIT or such. If I remeber correctly they upgraded to 6.something, but I might be all wrong.
~Mike
You want to look at AIXes no command as this enables 'tuning' of the kernel/TCP stack parameters.
From mem I'm not sure AIX4.3 has support for FIN closure parameter manipulation, I think this came in in AIX 5.1??.
Under linux you'd find it as:
net.ipv4.tcp_fin_timeout (in sysctl.conf)
From mem I'm not sure AIX4.3 has support for FIN closure parameter manipulation, I think this came in in AIX 5.1??.
Under linux you'd find it as:
net.ipv4.tcp_fin_timeout (in sysctl.conf)
- Status