tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Spies <jus...@thespies.org>
Subject Re: cpu 100% java
Date Wed, 02 Aug 2006 21:44:20 GMT
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message