Does my java application continue running while jmap is taking its memory dump?
Add a comment |
3 Answers
I had an issue with trying to do this on a production machine creating the hprof file with jmap took ages and naturally locked up the java webapp for ages.
I found this page:
http://blogs.atlassian.com/2013/03/so-you-want-your-jvms-heap/
Which explained that you can also use gdb (on linux systems) to dump the core of the java process.
With this core file you can then generate the hprof file for analysis in a separate process which prevent your java server process from being interrupted for such a long time. Which is what would happen if you were to run the same operation with jmap.
To summarise:
download and install gdb
apt-get update
apt-get install gdb
...
get the java process id of the java process you're interested in
jps ...
start a gdb session with that process
gdb [pid] ...
then generate the core file:
gcore /tmp/jvm.core
end the gdb session
detach quit
then use the core file generated to make an hprof file:
sudo jmap -dump:format=b,file=jvm.hprof /usr/bin/java /tmp/jvm.core
then (g)zip the file up and copy it to your machine for further analysis.
1 Comment
Sameer Naik
WayBackMachine snapshot of original article web.archive.org/web/20200810143815/https://www.atlassian.com/…
Your application is stopped. The only practical way to get an accurate heap dump would be to stop all application activity while the dump is being created.
Whether this is a "brief" pause or a "long" pause depends on how much is dumped. If you use "-dump" then you will dump the entire heap, including unreachable objects. If you use "-dump:live" you will only dump reachable objects ... but that also entails (at least) marking the heap to figure out which objects are reachable.
But if you are dumping a gigabyte sized heap, expect the pause time to be measured in minutes rather than seconds.
Re the suggestion that you could avoid stopping the JVM by using fork, it turns out that forking a multi-threaded process can be problematic:
- fork in multi-threaded program
- Multithreaded fork
- http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them
Then there is is the resource usage issue.
6 Comments
Ramon
Even if this is how most/all JVM's do it today, I'm not sure this is the "only way to get an accurate heap dump". You could also
fork and perform the heap dump from for child process. This would obviously use a lot of memory for the copy-on-write but probably not as much as 2x if you free pages as you go.
Stephen C
@Ramon. Changed "only way" to "only practical way".
AHungerArtist
@StephenC Would you expect the dump take minutes or even more for gigabyte+ sized heaps? It seems like it is growing the heap file very slowly and it is taking quite a long time.
Stephen C
@AHungerArtist - I would expect it to be relatively fast. However, a slow file system or not having enough physical memory (compared with the JVM's vmem size) could lead to long dump times.
Per Lundberg
I have a 7 GiB dump started 20 minutes ago where
jmap is still running... This is on Windows Server 2012 R2. |
I would say your program will pause briefly while the memory dump is taken. The memory dump is a snapshot in time of your running program, so jmap will need to lock the JVM briefly while that memory is read. To send the dump file back to the client however, could be done in a separate thread, thereby minimizing the pause.
