On Mar 4, 2014, at 6:32 AM, Rainer Jung <rainer.j...@kippdata.de> wrote:
> On 27.02.2014 23:06, Isaac Gonzalez wrote: >> Hi Christopher(and Konstantin), attached is a couple of thread dumps of when >> we experienced the issue again today. I also noticed we get this message >> right before the problem occurs: >> Feb 27, 2014 12:47:15 PM >> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run >> SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new >> native thread) executing >> org.apache.jk.common.ChannelSocket$SocketAcceptor@177ddea, terminating thread > > Is it a 32Bit system? You have 2GB of heap plus Perm plus native memory > needed by the process plus thread stacks. Not unlikely, that you ran out > of memory address space for a 32 bit process. > > The only fixes would then be: > > - switch to a 64 bit system > > - reduce heap if the app can work with less > > - improve performance or eliminate bottlenecks so that the app works > with less threads > > - limit you connector thread pool size. That will still mean that if > requests begin to queue because of performance problems, the web server > can't create additional connections, but you won't get in an irregular > situation as you experience now. In that case you would need to > configure a low idle timeout for the connections on the JK and TC side. It may also be possible to lower the thread stack size with the -Xss option. http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#threads_oom Might buy you some room for a few additional threads. Dan > > Regards, > > Rainer > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
