Am 20.04.2015 um 14:11 schrieb Thomas Boniface:
Hi,I have tried to find help regarding an issue we experience with our platform leading to random file descriptor peaks. This happens more often on heavy load but can also happen on low traffic periods. Our application is using servlet 3.0 async features and an async connector. We noticed that a lot of issues regarding asynchronous feature were fixed between our production version and the last stable build. We decided to give it a try to see if it improves things or at least give clues on what can cause the issue; Unfortunately it did neither. The file descriptor peaks and application blocking happens frequently with this version when it only happens rarely on previous version (tomcat7 7.0.28-4). Tomcat is behind an nginx server. The tomcat connector used is configured as follows: We use an Nio connector: <Connector port="8080" protocol="org.apache.coyote. http11.Http11NioProtocol" selectorTimeout="1000" maxThreads="200" maxHttpHeaderSize="16384" address="127.0.0.1" redirectPort="8443"/> In catalina I can see some Broken pipe message that were not happening with previous version. I compared thread dumps from server with both the new and "old" version of tomcat and both look similar from my stand point. My explanation may not be very clear, but I hope this gives an idea how what we are experiencing. Any pointer would be welcomed.
If the peaks happen long enough and your platforms has the tools available you can use lsof to look for what those FDs are - or on Linux looking at "ls -l /proc/PID/fd/*" (PID is the process PID file) - or on Solaris use the pfiles command.
If the result is what is expected, namely that by far the most FDs are coming from network connections for port 8080, then you can check via "netstat" in which connection state those are.
If most are in ESTABLISHED state, then you/we need to further break down the strategy.
Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
