I have a production server running with the following flag: -XX:+HeapDumpOnOutOfMemoryError
Last night it generated a java-38942.hprof file when our server encountered a heap error. It turns out that the developers of the system knew of the flag but no way to get any useful information from it.
Any ideas?
7 Answers
If you want a fairly advanced tool to do some serious poking around, look at the Memory Analyzer project at Eclipse, contributed to them by SAP.
Some of what you can do is mind-blowingly good for finding memory leaks etc -- including running a form of limited SQL (OQL) against the in-memory objects, i.e.
SELECT toString(firstName) FROM com.yourcompany.somepackage.User
Totally brilliant.
4You can use JHAT, The Java Heap Analysis Tool provided by default with the JDK. It's command line but starts a web server/browser you use to examine the memory. Not the most user friendly, but at least it's already installed most places you'll go. A very useful view is the "heap histogram" link at the very bottom.
ex: jhat -port 7401 -J-Xmx4G dump.hprof
jhat can execute OQL "these days" as well (bottom link "execute OQL")
You can also use HeapWalker from the Netbeans Profiler or the Visual VM stand-alone tool. Visual VM is a good alternative to JHAT as it is stand alone, but is much easier to use than JHAT.
You need Java 6+ to fully use Visual VM.
5Just get the Eclipse Memory Analyzer. There's nothing better out there and it's free.
JHAT is only usable for "toy applications"
4I personally prefer VisualVM. One of the features I like in VisualVM is heap dump comparison. When you are doing a heap dump analysis there are various ways to go about figuring out what caused the crash. One of the ways I have found useful is doing a comparison of healthy vs unhealthy heap dumps.
Following are the steps you can follow for it :
- Getting a heap dump of OutOfMemoryError let's call it "oome.hprof". You can get this via JVM parameter HeapDumpOnOutOfMemoryError.
- Restart the application let it run for a bit (minutes/hours) depending on your application. Get another heap dump while the application is still running. Let's call it "healthy.hprof".
- You can open both these dumps in VisualVM and do a heap dump comparison. You can do it on class or package level. This can often point you into the direction of the issue.
link :
YourKit Java Profiler seems to handle them too.
If you want to do a custom analysis of your heapdump then there's:
- JVM Heap Dump Analysis library
This library is fast but you will need to write your analysis code in Java.
From the docs:
- Does not create any temporary files on disk to process heap dump
- Can work directly GZ compressed heap dumps
- HeapPath notation
