Is it anyhow possible to use a process dump created by windows taskmanager for analysis on Eclipse Memory Analyzer?
At least Eclipse Memory Analyzer cannot open the dump. So is there any conversion? I already searched on google, but did not find anything, yet. So I think there is no way? Also here on Stackoverflow I did not find anything useable.
No, that's not possible.
The dump must be from the Java virtual machine. The dump created by the Windows task manager is on machine code instead on bytecode level.
See in the Memory Analyzer (MAT) help how to create a dump that can be analyzed with MAT
Related
My Java program is taking up huge amounts of memory ~3GB and I have set xmx300MB. Additionally different tools report different memory usage.
jcmd: 576MB
Task Manager: 967MB
Resource Monitor: 3478MB
When I close the program Task Manager shows the memory usage dropping by about 3GB. My question is how can I see what is using this memory? It seems like it is not java due to the output I see by jcmd. I suspect it might be a DLL that my Java program is using. Are there any tools which can be used here?
Here's a toolset and instructions.
You can first confirm your suspicions that it is the DLL by enabling Native Memory Tracking with -XX:NativeMemoryTracking=summary (or detail), then re-check with jcmd VM.native_memory to verify it's not Java doing native memory allocation.
If you don't see a large obvious chunk under the Native Memory Tracking part, you'll be out of Java land and have to try the tools listed in "Native Memory Leaks from Outside the JVM" (jemalloc, valgrind, Purify, etc.).
I have a very peculiar problem. I have a heap dump of 30 GB and I want to analyze the same on my laptop (which has 8 GB of RAM). I tried doing that with MAT and IBM Heap analyzer, but as per their recommendation the Xmx size should be more than the dump size. I also tried to analyze the heap dump with the heapDumpParser.bat file of MAT but received memory error.
Any suggestions on how I can analyze the dump on my laptop successfully?
Thanks in advance!
Memory Analyzer is probably the best tool for analysing out of memory issues but it does require a lot of memory.
If you are unable to find a machine large enough to run to handle your dump you could try using the jdmpview command line tool that ships with the IBM SDK to perform some basic investigation.
It will work best with the core dumps generated on out of memory rather than the phd files as it does not need to load the contents into memory.
You can find it in jre/bin and need to run:
jdmpview -core core_file_name
You should probably start by running the command:
info class
as that will generate a basic list of object types, instance counts and sizes.
There are full docs here:
http://www-01.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.win.80.doc/diag/tools/dump_viewer_dtfjview/dump_viewer.html
The application i am working on suddenly crashed with
java.io.IOException: ... Too many open files
As i understand the issue it means that files are opened but not closed.
Stacktrace of course happens after the fact and can only help understand before what event error occurred.
What would be an intelligent way to search your code base to find this issue which only seems to occur when app is under high stress load.
use lsof -p pid to check what cause leak of file references;
use ulimit -n to see the limit of opened file references of a single process;
check any IO resources in your project,are they released in time?,Note that,File,Process,Socket(and Http connections) are all IO resources.
sometimes, too many threads will cause this problem too.
I think the best way to use a tool specifically designed for the purpose, such as this one:
This little Java agent is a tool that keeps track of where/when/who opened files in your JVM. You can have the agent trace these operations to find out about the access pattern or handle leaks, and dump the list of currently open files and where/when/who opened them.
In addition, upon "too many open files" exception, this agent will dump the list, allowing you to find out where a large number of file descriptors are in use.
I seem to remember YourKit also having some facilities around this, but can't find any specific information at the moment.
What OS? If it's linux/mac, there is information under /proc that should help. On Windows, use the Process Explorer.
As far as searching the code base, perhaps look for code that catches or raises IOException - I think I/O methods that already catch/raise this have a high likelihood of needing a close() call.
Have you tried attaching to the running process using jvisualvm (Java 5.0 and later in the JDK bin directory). You can open the running process and do a heap dump (which if you have an older JDK you will need to analyze using eclipse or intellij or netbeans et. al.).
In JDK 7 the heap dump button is under the "Monitor" tab. It will create a heap dump tab, "Classes" sub-tab that you can check and see if any classes that open files exist in high quantity. Another very useful feature is heap dump compare, so you can take a reference heap dump, let your app run a bit and then take another heap dump and compare the two (the link to compare is on the "[heapdump]" tab you get when you take one. There is also a flag in java for taking a heapdump on crash or OOM exception, you can go down that route if comparing heap dumps does not give you an obvious class that is causing the problem. Also, "Instances" subtab in the heap dump diff will show you what has been allocated in the time between the two heap dumps which may also help.
jvisualvm is an awesome tool that does not get enough mentions.
I have a windows memory dump (DMP) file of a JVM process.
Is there any way I can use Java tooling to do a heap analysis of this? The SDK tools (jhat etc.) don't seem to help - they all seem to expect a Java heap dump.
(I've plenty of Windbg experience, but I am a complete ignoramus when it comes to Java debugging)
This similar question: Dump file analysis of Java process? has no answer on this point.
See my other answer covering exactly that, how to get Java information from Windows minidump
If i understood your question properly then i would suggest you to use jconsole you can find under jdk.
You can find API here
http://docs.oracle.com/javase/6/docs/technotes/tools/share/jconsole.html
Say your application is unresponsive and you cannot attach a debugger to it, as it rejects everything. All you have is a Linux Bash and process id. How would you investigate the issue? What tools would you use? My goal is to better my troubleshooting skills using Java.
This particular issue we had in production, on customer site.
You could take a thread dump from the application by issuing:
kill -3
That would give you some information as to the current state of the threads and hopefully help diagnose the issue. However, the trick is not in taking the thread dump, but reading the thread dump produced - since they can be a little overwhelming to look at. See this link for more info on reading a thread dump.
http://manikandakumar.blogspot.com/2006/12/reading-thread-dumps.html
You could also take a look at jstack which is part of the JDK - I've not used it specifically, see:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstack.html
I agree with Jon that you should use kill -3 to get a thread dump. I have found Thread Dump Analyzer useful for viewing thread dumps.
You should also take a look at the memory usage of the process using top. Does it look like the app has run out of heap space? If so, you could try and use the jmap tool to obtain a heap dump and/or histogram count of the objects on the heap. You may need to use the -F option if the app has really hung up and I have experienced cases where jmap simply would not work against a hung Java process. Once you have a heap dump you could use Eclipse Memory Analyzer to investigate it.
You don't mention whether your application has any logging. If not you should look into adding logging that could help debug production issues.
jstack <pid>
Sounds like an interview question.
You could also try attach jconsole to see what it is doing.
If you have Java 6 you can try to connect with Visualvm (https://visualvm.dev.java.net/) which ships with current JDKs to connect to the VM. With this Tool you are able to create a complete MemoryDump (not only thread dump) of your VM Process. You can load this Memory Dump into VisualVM or Eclipse with the MAT Plugin (Memory Analyzer Tools http://www.eclipse.org/mat/).
After some time of loading an computation you can browse the complete Heap of your Application, search form Memory Leaks etc.
Analysing Heap Dumps is a great way to improve your TroubleShooting Skills.
I agree with others that Thread dumps are the way to go.
I would like to add that you should get lot's of thread dumps.
You can do very simple profiling with just a few unix commands.
Check my post here
I know this is an old question but I would like to share information with our other friends who are facing this issue and come across this post.
You can capture the thread dump and use some tools like fastThread, Samurai to analyze your thread dumps.
You can check out the following blog to see 8 different options to take thread dump: How to capture thread dump?