Aha, for some reason, I thought perm gen was included in the general heap so
the maximum for the two combined was constrained by the 2400m I had defined
for the heap. Somewhere around 2:00AM (I am US east coast), I can restart
the server with the new settings.
I have taken several heap dumps (using Visual JVM) and nothing looked odd.
Also, I can see (from Visual JVM) that the GC runs reasonably frequently
when the heap grows (from users working) but the total heap is generally
under 1GB. I wonder if the sneaky little bugger, under load, just pushes to
OOM and I am running so close to the edge that I don't see it. Odd though,
I have forced OOM issues in the past and they always showed up in
catalina.out.
Thanks for your thoughts and help.
Carl
----- Original Message -----
From: "Pid" <p...@pidster.com>
To: <users@tomcat.apache.org>
Sent: Monday, January 11, 2010 8:07 PM
Subject: Re: JVM goes away
On 11/01/2010 23:06, Peter Crowther wrote:
2010/1/11 Carl<c...@etrak-plus.com>:
This is a new server, a Dell T110 with a Xeon 3440 processor and 4GB
memory. I have turned off both the turbo mode and hyperthreading.
The environment:
64 bit Slackware Linux
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)
Tomcat: apache-tomcat-6.0.20
JAVA_OPTS="-Xms2400m -Xmx2400m -XX:PermSize=512m -XX:MaxPermSize=512m"
I have watched observed the memory usage and general performance with
Java VisualVM and have seen nothing strange. GC seems to be performing
well and the memory rarely gets anywhere near the max.
The server runs well, idling along at 2-5% load, serving jsp's, etc. at
a reasonable speed. Without warning and with no tracks in any log
(Tomcat or system) or to the console, the JVM will just go away,
disappear. Sometimes, the system will run for a week, sometimes for
only several hours. Initially, I thought the problem was the turbo or
hyperthreading but, no, the problem persists.
When the JVM goes away, the memory that it held is still being held (as
seen from top) but it is nowhere near the machine physical memory.
The application has been running on an older server (Dell 600SC, 32 bit
Slackware, 2GB memory) for several years and, while the application will
throw exceptions now and then, it never crashed the JVM. This leads me
to believe the problem has something to do with the 64 bit JVM but, with
errors, I can't be certain and don't know what I can do about it except
go back to 32 bit.
I plan to reinstall Java tonight but, it would seem if the JVM were
corrupted, it simply would not run.
Any ideas are welcome.
I'm with Andy: the Linux OOM killer would show those symptoms. With
those settings, you're not leaving a lot of memory for the OS. How
much swap do you have, and does the same thing happen if you reduce
the Java heap and permgen space?
- Peter
Despite later posts, I'm leaning towards agreeing with the above, based on
the information provided.
N.B. Maximum heap size does not equal the maximum memory a JVM can/will
use.
The Perm generation is in addition to the heap so you're effectively
saying that the memory you want to use is 2400 + 512 (+ other stuff
falling into the non-heap category).
So you may be using more than 3Gb; jmap -heap <pid> will provide more
information, you could regularly dump the output to file to see what's
happening with the JVM.
http://java.sun.com/javase/6/docs/technotes/guides/management/jconsole.html
(Confession: I'm not sure I've got my head round it yet)
An OOM should leave a trace somewhere on your system, it might be a single
log entry saying that a given process id has been terminated.
Google for specific info for your OS.
p
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
