Ben,
For various reasons, I've had to send this response using your
original message. I've included below some of the feedback provided
by Chris since I'm pretty sure I'v read the entire thread so far...
I've run into this type of issue many times as well, memory management
definitely is not automatic in Java, at least not for admins.
[Hide Quoted Text]
Think the Java that is hogging the cpu is something different.
I run /Library/Tomcat/bin/startup.sh (with ram settings)
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE
VSIZE
1792 java 27.9% 0:08.83 12 255 191 47.9M+ 13.1M 35.6M+
469M+ (using -Xms128m -Xmx256m)
This application looks to not be using much of the heap. What you see
is that the system is using only about 50MB of memory. According to
http://www.mozilla.org/projects/footprint/OSX_opt_mem_usage.txt
however, the numbers add up the opposite (the document says that
47+13=3D3D35, but it looks more like 13+35=3D3D48)
The VSIZE question--when the JVM starts, it places a hold on the
memory it thinks is needed. So if you allocate a maximum heap of
256MB + the permanent size of 128MB (which I realize you haven't set
and I don't recall the default) + extra overhead memory =3D3D 469MB of
VSIZE. Note that the JVM needs memory, as Chris mentioned, of HEAP +
PERMSIZE + (THREADMEMORY * NUM THREADS).
To check memory usage, you'll want to add the following to your
startup parameters (plus any others you want):
-verbose:gc -Xloggc:/tmp/garbage.log -XX:+PrintGCTimeStamps -XX:PrintGCDetai=
=3D
ls
The above will tell you how much memory is being allocated and how
often the system is doing garbage collection.
Details for reading and understanding the log files can be found at
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html (jvm 1.5)
http://java.sun.com/docs/hotspot/gc1.4.2/ (jvm 1.4.2)
I've seen weird issues with the different garbage collectors as well,
for example we have an application in BEA WebLogic on a Sun server
where using the ConcMarkSweep collector caused a core dump. I've also
seen JVM's on Linux hard lock in the middle of a GC and the CPU spike
to 100% utilization. Only a kill -9 would kill the process.
[Hide Quoted Text]
but this one is still around
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE
VSIZE
1775 java 98.8% 0:56.40 21 597 243 88.3M 9.94M 77.8M
288M (one that hogs cpu, the problem process from the start)
I do /Library/Tomcat/bin/shutdown.sh and I only have the pid 1775 (hog
one) other java is gone now.
I haven't used a Mac in about 8 mo, so I don't recall the details of
the startup / shutdown for Tomcat, however this could be due to the
high load & the shutdown command cannot communicate with the Tomcat
instance.
Also note that the above instance is using much more REAL memory
(88MB) than the first instance, but has much less total allocated
memory (288MB). It's highly likely that the application is defaulting
to a heap size of something like or 9MB.
Since this is the instance causing problems, you'll probably want to
use the above JVM arguments for this instance. Note that you probably
cannot put the -Xloggc:/tmp/garbage.log into a shared startup script.
Any instance started with that script would write to the same file,
destroying / contaminating your data.
[Hide Quoted Text]
Two Java programs:
Ran by Appserve "java
-Djava.endorsed.dirs=3D3D/Library/Tomcat/common/endorsed -classpath
/Library/Java/Home/lib/tools.jar:/Library/Tomcat/bin/bootstrap.jar
-Dcatalina.base=3D3D/Library/Tomcat/blojsom_root
-Dcatalina.home=3D3D/Library/Tomcat
-Djava.io.tmpdir=3D3D/Library/Tomcat/blojsom_root/temp
org.apache.catalina.startup.Bootstrap start"
(weblogs use this one, seems to be the problem one, any idea where the
config is for this one?)
Ran by Root
"/System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home/bin/java
-Xms128m -Xmx256m -Djava.endorsed.dirs=3D3D/Library/Tomcat/common/endorsed
...." so this one is using the ram change -Xms128m -Xmx256m other is
not.
It's tough to tell what's going on with this:
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE
VSIZE
825 java 102.4% 2:43:34 61 >>> 371 98.0M 872K 85.1M-
308M
RSIZE (resident size, IIRC) is 85.1M - 308M? WTF does that mean?
If the 308M is spurious, then your Java process was using 85MB which
suggests that your heap size was probably more like 64MB or somewhere in
there. Increasing it to 128/256 as you have above ought to give you some
more room to move around in.
Does this help the problem?
-chris
Ben
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
