Some times your application might face OutOfMemoryError. Here is a startegy to diagnose the problem:
1. Make sure you have turned on your garbage collection log. Garbage collection log would indicate in which area of the heap (young generation, old generation, survivor, perm generation …) problem is surfacing. It would also indicate how long garbage collection is running. It’s very easy to turn on garbage collection log.
2. Start the JVM with following system properties:
-XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/user/foo/java_pid<pid>.hprof
This property would take heap dump automatically when JVM experiences OutOfMemoryError. Captured heap dump would be placed in “/user/foo/java_pid<pid>.hprof”. This is a great safety net, in case your operations team misses to catch the heap dump before JVM crashes.
3. Make sure application has initialized completely. Now take a heap dump manually.
4. Let the JVM run.
5. Next time when JVM experience OutOfMemoryError, it would automatically capture heap dump based on the property instrumented in step #2.
6. Analyze the two heap dumps (taken in step #3 and #5). It would indicate leaking objects in memory. Once leaking objects are identified, root source of the problem can be easily identified.
How to turn on Garbage collection log?
In general it’s a good practice to have GC log turned ON always. It would add un-noticeable overhead (if any) to the JVM.
-verbose:gc -Xloggc:/user/foo/gc.log -XX:+PrintGCDateStamps
It would start the Garbage collection log to go in to “/user/foo/gc.log”. “-XX:+PrintGCDateStamps” would also make the GC log lines to carry the date/time stamps.
GC logs can be analyzed using Tier1app’s Universal GC Analyzer.
tier1app 