tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <Chuck.Caldar...@unisys.com>
Subject RE: Tomcat 100% CPU usage after moving from Java 5 to 6
Date Tue, 26 Jan 2010 15:38:18 GMT
> From: Jesse Klaasse [mailto:jesse.klaasse@indicia.nl]
> Subject: Re: Tomcat 100% CPU usage after moving from Java 5 to 6
> 
> I found the following article particularly useful:
> http://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues

Unfortunately, that article is so full of mistaken assumptions and outright errors that it
must be taken with a large chunk of salt.  There are some good things in it, but also a lot
of rubbish.  Among other things, the author is obviously unaware of how paging systems work,
confusing contiguous virtual memory (required for the heap) with contiguous real memory (not
required at all).
 
> -XX:+UseConcMarkSweepGC

This will reduce overall throughput, but also reduce the GC pause time.  (GC pause time is
pretty small even without that parameter these days.)  It does make the GC threads do a lot
more work, but you appear to have CPU time to burn.

>-XX:+UseTLAB

This has been the default for quite a few years now, so it's unnecessary to specify it.

>-XX:+CMSClassUnloadingEnabled

The above slows down CMS collections.  You can leave it off if you never update JSPs on the
fly, or redeploy webapps without a Tomcat restart.

>-XX:+CMSPermGenSweepingEnabled

The above is the old name for CMSClassUnloadingEnabled and should not be used.

>-XX:+DisableExplicitGC

Always a good idea to set the above.

>-XX:NewSize=4096m

I would be wary of setting the above parameter, preferring to let the JVM determine the value
as needed.  JDK/JRE 6 is much better at reacting to dynamic changes in workload than 1.4 was.

>-Xms10240m -Xmx10240m

That's a very large heap; shouldn't hurt as long as you have enough RAM to support it all
without paging.  (But see below for use with compressed OOPs.)

> Tomcat's CPU usage seems significantly lower than before 
> (it's average seems about 10% now - which was 30-40% before)

There are some improvements in the JDK/JRE 6 JIT and synchronization handling, but probably
not enough to account for that large a difference.

> I also added the -XX:+UseCompressedOops JVM option

Be careful with that; it can impact CPU usage, since the compressed OOPs have to be expanded
into actual pointers every time they're used, and pointers compressed when stored in a field.
 Works best with heap sizes less than 4 GB, which avoids the decoding/encoding.  For a real
explanation of compressed OOPs, look here:
http://wikis.sun.com/display/HotSpotInternals/CompressedOops

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus
for use only by the intended recipient. If you received this in error, please contact the
sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message