André Warnier wrote:
Radha Krishnan D wrote:
Hi
Am sorry, clicked submit by mistake
The below is the actual problem
We are running into too many open files exception on our production
tomcat server for the last 2-3 days.
We have max threads as 150 and acceptCount as 100 and at one point of
time all the 250 threads are busy processing requests (due to
application related issues)
At peak times, when all the threads are busy, new requests are
rejected by tomcat.
Nearly 40 mins to 1 hr after the rejections begin, there are too many
open files exception coming on the tomcat server..
The number of file descriptors is 16384 and we are getting 50-60
requests per sec.
What can be the root cause here. After rejecting a request, is the
socket not closed immediately and this results in pile up of open
files or is there some other reason ?
Can any one help us in this regard ?
platform/OS version ?
Java version ?
Tomcat version (x.y.z) ?
"The number of file descriptors is 16384.." : where does that number
come from ?
And are they sockets or other things ?
"After rejecting a request, is the socket not closed immediately and
this results in pile up of open files or is there some other reason ?"
There are some "states" in TCP/IP, that a connection goes through even
after a close() has been issued by the server side. There are some
delays there, and maybe that is a source for your problem. Google for
"TCP state diagram".
Use "netstat" and "lsof" (under Unix/Linux) to find out more.
See also this
http://stackoverflow.com/questions/34588/how-do-i-change-the-number-of-open-files-limit-in-linux
The point is : your system(s) may really be too small to handle the load that comes to
them; or your application may be too slow to respond; or you may have KeepAlive set too
high for your own good, or any of the parameters here that can be used to "modulate" what
happens could be wrong for your case :
https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Standard_Implementation
But all these parameters are to some extent interdependent, and before "tuning" any of
them, you would need to have (and provide us with) a better picture of what really
happens. If you start playing around with them without really understanding what is
happening and what you are doing, you'll probably make the situation worse, not better.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org