Eric, if you are looking for a reasons and think, what can be done with OOMs, take a look at this page: http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html There is an options: -XX:-HeapDumpOnOutOfMemoryError - it will make heapdump on OOM. -XX:HeapDumpPath=./java_pid<pid>.hprof - give it an reasonable path to file.
After you get an heapdump - use Eclipse Memory Analyzing Tool, there is an effective Find Leak Suspects report, and also Dominator Tree. https://www.dropbox.com/s/m2kgvel22vjjrzv/screenshot_000122.png?dl=0 - this is an example. This way I've found an memory leak in BoneCP, for example. https://www.dropbox.com/s/3v0tb56b5uu7ub6/screenshot_000123.png?dl=0 - look, 634M of SybConnections (Sybase ASE connection). https://www.dropbox.com/s/64qsm9wd5ls1h5v/screenshot_000124.png?dl=0 - Each SybConnection occupy from 14M to 45M of heap. https://www.dropbox.com/s/p2qpqmn9r65481i/screenshot_000125.png?dl=0 - Dominator Tree will show, what is the reason, in my case it was a bunch of SQLWarnings in each connection. Also you can monitor a server instance with JVisualVM. Use VisualGC plugin to visualize, what's happening with your Tomcat's heap in detail: https://www.dropbox.com/s/za36q46v765gltf/screenshot_000126_cut.png?dl=0 (VisualGC is a downloadable plugin to JVisualVM, JVisualVM can be found in the bin directory of installed JDK). You may also need to launch jstatd with the same user, which launched Tomcat to be able to monitor Tomcat remotely. Good luck! :) 2015-03-19 3:35 GMT+02:00 Caldarale, Charles R <chuck.caldar...@unisys.com>: >> From: Eric Robinson [mailto:eric.robin...@psmnv.com] >> Subject: Java Heap Space / Thread Dump Numbers > >> 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? > > 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 > > - 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
