On 03/05/2012 18:21, Christopher Schultz wrote:
-----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.
Site became unresponsive. When I saw in catalina.out that the connector
was pausing and the website was not responsive, I checked the java
process and was dead, so I couldn't get a thread dump
If you can't take a thread dump during these "pauses", you'll never
know what is happening.
Any setting that can generate a dump automatically as for out of memory
errors?
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).
Yes, a mysql database and pooled connections. How can I enable that
abandoned tracing?
I enabled slow queries for mysql, but the developer claims the queries
are fine (although some report more than a second to be run).
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.
Well, before the heap size was 512m so I have increased it just a little
(to overcome the outofmemory errors). Is that increase that much?
I can revert the GC strategy. the verbose options for GC are fine?
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.
I'll retake that path of checking mysql indexes and slow queries.
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.
That we have outgrown our hardware, that's probably for sure. This a
virtual private server. I have said the owners to move to a dedicated
server but I guess they want me to squeeze this VPS as much as I can.
Miguel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
