> From: Michael Simmons [mailto:[EMAIL PROTECTED] > Subject: RE: JMX Perform GC TOMCAT 5.5.23 > > So.. giving the JVM many 1000s of times the space taken by > live objects (even under very high load) is a waste.
Not at all. Having lots of room for short-lived object creation extends the time between GCs. > Should I have said "Allocating a huge amount of memory to the > JVM isn't always useful."? Depends on the characteristics of the application. Usually, the largest heap possible that doesn't push the system in paging is the most efficient. > In my experience using UseConcMarkSweepGC (or whatever it > is under 1.6) and tuning the Eden heap size does make a big > difference to a server application (tomcat) under continuous > high load. Not unexpected. The concurrent GC mechanism is designed to minimize pause times but at the expense of quite a bit more overhead during collections. It's not on by default because of the throughput impact; if response time is more important than throughput, then it *might* be useful to enable the concurrent algorithm. You'd have to test in your own environment to see if it's beneficial. Changing the eden size can also have a dramatic effect on GC frequency, since nearly all objects are created in eden and then moved to a survivor space when eden fills (if still referenceable). If there's an imbalance between eden, survivor, and tenured space sizes, GC efficiency can fall off rapidly. The GC ergonomics feature in 1.5 and 1.6 is an ongoing effort by the HotSpot developers to dynamically balance the heap regions based on current conditions within the JVM; specifying explicit sizes for any of the regions may well end up with worse performance than just letting GC figure it out. If your webapps create lots of short-lived objects, you might want to experiment with different values for TLABSize; we found that had a major affect on performance in multi-processor systems. Also try setting -XX:+AggressiveHeap; it may or may not be beneficial, depending on your situation. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
