-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miguel,
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+isHgACgkQ9CaO5/Lv0PBeJQCePi3qq6ZF8DuuMgooQtnBuLJA NeUAoJ8HChlhmkiUCqkkLAAtY3X8PJKK =jgRd -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
