Post by Barry MargolinPost by Pete EhlkeAt any rate, I don't recall you telling us what OS you run, but
http://www.sean.de/Solaris/tune.html used to be of some use on Solaris
web servers, but tuning a web server and tuning a name server are *vastly*
different enterprises, and even at that, really affecting CLOSE_WAIT (as
opposed to TIME_WAIT) is *hard*.
CLOSE_WAIT isn't something you can tune away. In this case, it suggests a
bug in the server -- it isn't closing the connection after it's done
sending the response.
W. Richard Stevens backs up Barry:
FIN WAIT 2 State
In the FIN_WAIT_2 state we have sent our FIN and the other end has
acknowledged it. Unless we have done a half-close, we are waiting for
the application on the other end to recognize that it has received an
end-of-file notification and close its end of the connection, which
sends us a FIN. Only when the process at the other end does this close
will our end move from the FIN_WAIT_2 to the TIME_WAIT state.
This means our end of the connection can remain in this state forever.
The other end is still in the CLOSE_WAIT state, and can remain there
forever, until the application decides to issue its close.
Many Berkeley-derived implementations prevent this infinite wait in the
FIN_WAIT_2 state as follows. If the application that does the active
close does a complete close, not a half-close indicating that it expects
to receive data, then a timer is set. If the connection is idle for 10
minutes plus 75 seconds, TCP moves the connection into the CLOSED state.
A comment in the code acknowledges that this implementation feature
violates the protocol specification.
...this is from TCP/IP Illustrated Vol 1.
--
Nate Campi | Terra Lycos DNS | WiReD UNIX Operations
He may look like an idiot and talk like an idiot but don't let that fool
you. He really is an idiot. - Groucho Marx