Increasing the amount of opened file descriptors is an accepted fine-tune (*if your application it is handling the threads properly*)
ulimit -n ulimit -n [new_value] ulimit -n If even after allowing more fds the performance is not adequate, some sort of scaling (H/V) is necessary. On Mon, Apr 20, 2015 at 3:41 PM, Rainer Jung <rainer.j...@kippdata.de> wrote: > 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: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
