Am 20.04.2015 um 15:41 schrieb Rainer Jung:
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.
One more thing: the connection peak might happen, if for some reason
your application or the JVM (GC) gets slow. The reason doesn't have to
still be there at the time when you take the thread dump.
You might want to add "%D" to your Tomcat access log and ty to estimate,
whether the connection peaks are due to (temporary) application slow down.
The same holds for activating a GC log and check for long or many
cumulative GC pauses.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
