One more reason why we use this much memory: we run 2-4 contexts most of the
time. This was originally done to separate certain customer data while
keeping the code base the same and to allow us to have a test environment
exactly like the production environment. If each context requires 50-60MB
for perm gen, then the Tomcat perm gen is upwards of 256MB. Also, if each
context requires 200-300MB of heap, then we could require upwards heap of
500-700MB (allowing for GC, timing, etc.) I have probably allocated more
heap memory than needed (due to my faulty understanding that the heap
constrained perm gen, etc.)
Thanks,
Carl
----- Original Message -----
From: "Pid" <p...@pidster.com>
To: "Carl" <c...@etrak-plus.com>
Sent: Tuesday, January 12, 2010 4:41 AM
Subject: Re: JVM goes away
On 12/01/2010 01:30, Carl wrote:
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.
Does your app actually need all that memory?
p
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
