> PSYoungGen total 95808K, used 22323K [0x00002aaac3770000, > 0x00002aaaca210000, 0x00002aaaca210000) > eden space 82432K, 10% used > [0x00002aaac3770000,0x00002aaac402f7f8,0x00002aaac87f0000) > from space 13376K, 99% used > [0x00002aaac87f0000,0x00002aaac94fd5a8,0x00002aaac9500000) > to space 13376K, 0% used > [0x00002aaac9500000,0x00002aaac9500000,0x00002aaaca210000) > PSOldGen total 177792K, used 144800K [0x00002aaab6210000, > 0x00002aaac0fb0000, 0x00002aaac3770000) > object space 177792K, 81% used > [0x00002aaab6210000,0x00002aaabef78110,0x00002aaac0fb0000) > PSPermGen total 120960K, used 65149K [0x00002aaaae210000, > 0x00002aaab5830000, 0x00002aaab6210000) > object space 120960K, 53% used > [0x00002aaaae210000,0x00002aaab21af440,0x00002aaab5830000)
> Which of those lines represents the heap space? Chuck Caldarale wrote: // Actually, all of them. The JVM's heap is not just a simple collection, but is instead a somewhat complex structure designed to facilitate garbage collection. A brief description of the components: eden space - where most objects are born (and most of them die) from-space - where live objects exist after a minor garbage collection to-space - where objects will be copied to during a minor garbage collection old gen object space - where long-lived objects reside perm gen object space - where instances of java.lang.Class reside Normally sized objects are initially created in eden. When eden fills, a minor GC copies most live objects from eden and the from-space into the to-space; objects that have been around a while are instead put into old gen. At the end of the minor GC, the from- (now empty) and to-spaces swap roles. When things get too full, a major GC is initiated, which squeezes out any dead space from the old gen. One exception to the above is allocation of large objects, which are placed immediately into old gen. Your OOME may be due to attempting to allocate something big. Since you didn't provide any information about the JVM version, GC settings, platform you're running on, or what your applications do, it's hard to say whether or not your heap is sized appropriately. However, your total of around 262M is rather small in this age of 64-bit machines with multiple gigabytes of memory. More information (not all of it up to date): http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140228.html // Thanks for the feedback. We run various versions of RHEL (5.5 to 6.3) x64. Tomcat is mostly 6.0.18. Java is mostly 6u21 x 64. Typical startup options looks like this... JAVA_OPTS="-Xms192M -Xmx384M \ -XX:MaxPermSize=128M \ -Djvm=$JVM_ID \ -Djava.awt.headless=true \ -Djava.net.preferIPv4Stack=true \ -Duser.timezone=US/Pacific \ -Xloggc:/alley/site214/tomcat6/logs/gc.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails \ $JPDA_OPTS $JMX_OPTS" The memory allocation seems low to you because we run many instances of tomcat on the same server. Although the servers have 32-64GB of RAM, the individual tomcat/java instances are kept fairly low. We are trying to be proactive by watching the memory usage numbers in the thread dumps. When we see a number that could be getting too close for comfort, we increase the memory allocation slightly and restart the tomcat. (We can get away with this in production because of the way our load balancing works it does not cause any downtime for clients.) Any thoughts on what numbers we should watch closest? The from space is always mostly used, but that does not appear to cause a problem. --Eric --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
