> From: Jesse Klaasse [mailto:jesse.klaa...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
