tom...@habmalnefrage.de wrote:
cute domain name ;-)
- all connections shown by netstat -an (not filtered): 4595
- connections in state close_wait: 3152
> Due to problems with one of our webapps which sometimes does not close
> > the threads completely (they stuck in close_wait-state) we increased
> > the max threads of windows:
So fix your webapp.
> >
I'll concentrate on that same one too.
We have an issue on some systems, which may be similar. Sometimes the
system becomes apparently incapable of responding to TCP connections at
all, and we have linked this to a high number of connections in the same
CLOSE_WAIT state. In our case, they are due to a webapp (of which we do
not have the source), which allocates some kind of "connection object"
which itself contains a socket. When the webapp terminates, it discards
this "connection object", but does not previously close() the socket.
These objects then sit on the Heap until the next GC, and meanwhile they
keep their socket in the CLOSE_WAIT state.
When there are "enough" of them in that state, we start having severe
problems on the system with other applications needing to connect to, or
from, the system. ("enough" is a vague number ranging from hundreds to
thousands, depending on the system).
Triggering a GC of Tomcat solves the problem, immediately : the
discarded objects get cleaned up, which frees the underlying sockets,
and the CLOSE_WAIT list disappears, and the system is back to normal.
I am not the great authority in those matters, but intuitively I would
imagine that a socket is an OS-level structure, and that it uses some
system resources, like RAM. And if you have thousands of them lying
around, it may matter.
The funny part about this, is that if you increase the Heap size, you
actually make the matter worse : there will be more room for these
discarded objects, delaying the time when a GC would occur. So you can
accumulate a lot more of them, and freeze a lot more resources with them.
To force a GC, one useful command line tool is available here :
http://code.google.com/p/jmxsh/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
