tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat pausing and no java process
Date Thu, 03 May 2012 16:21:12 GMT
Hash: SHA1


On 5/3/12 11:37 AM, Miguel González Castaños wrote:
> We had several crashes today:
> First - 1 outofmemory error Second- 3 Tomcat pausing

Do you mean that Tomcat actually paused its connectors, or do you mean
that your site became unresponsive? Were you able to capture a thread
dump during this unresponsive period? Did the JVM recover or did you
have to kill it and restart. If you had to kill it, that's called
beign "locked-up" and not just pausing for a while.

If you can't take a thread dump during these "pauses", you'll never
know what is happening.

Are you using a database? Are you using pooled connections? If so,
enable "abandoned" tracing if that's a possibility for you (Tomcat's
two built-in choices of dbcp can do abandoned tracing).

> Third - 2 or 3 times where catalina.out didn't show any error and
> tomcat died, only a big increase of memory use right before the
> java process died. That's why I assumed that maybe I have set the
> heap memory too high (I set it up because of the out of memory
> errors). That's why I googled to see if anyone had seen issues and
> that's why I reached that URL
> I have set up this:
> -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -Xms128m 
> -Xmx768m -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails

Great, so you've changed heap size *and* GC strategy and you still
have no idea what the problem is.

We had a performance problem last week that was very severe. One of my
friends said "well, if you're not using concurrent mark-and-sweep,
then that's probably the problem".  (I'm not sure of the nuances, but
the default GC on my system is "ConcurrentMarkSweep", so I don't know
if UseConcMarkSweepGC actually gets you anything). I was skeptical. I
did my research.

The problem was a missing index on a database table. A simple ALTER
statement changed 20-second response times back to more reasonable
sub-100ms response times. No mucking-around with the JVM required.

That's hy I suggest that you do some research *in your own
environment* instead of just guessing at random things and changing
every setting that you've found via Google.

> I hope this way I can trace if there is any memory leak in the
> webapp.

If you have a memory leak in your webapp and you have javamelody, I
would argue that you should set your heap to the /largest/ you can
possibly get away with and then watch it over time. A memory leak is
easy to see over time with a big heap. You are limited by a 32-bit JVM
and only ~1.5GiB heap limit, so it might be hard. Maybe you've just
outgrown your hardware.

> Considering that the developer decided to restart Tomcat once a
> week because the webapp didn't have enough resources, I find this
> very likely.

If you have a memory leak, changing the heap size and GC strategy
isn't going to help you at all: it will just waste your time.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message