This post originated from an RSS feed registered with Java Buzz
by Mathias Bogaert.
Original Post: So you want your JVM’s heap…
Feed Title: Scuttlebutt
Feed URL: http://feeds.feedburner.com/AtlassianDeveloperBlog
Feed Description: tech gossip by mathias
Abstract Dumping a JVM’s heap is an extremely useful tool for debugging problems with a J2EE application. Unfortunately, when a JVM explodes, using the standard jmap tool can take an inordinate amount of time to execute for lots of different reasons. This leads to extended downtime when a heap dump is attempted and even then, jmap regularly fails. This blog post is intended to outline an alternate method using standard tools in the Unix/Linux arsenal to achieve a heap dump that only requires mere seconds of additional downtime allowing the slow jmap process to happen once the application is back in service. Credits Thanks to Paul de Audney, fellow Atlassian Sysadmin Team Lead, who floated the idea for this a while ago. Our friend, the JVM The beauty of a JVM is it’s isolation from the underlying OS. This makes it attractive to both programmers and system administrators alike, but generally, makes debugging problems harder for everyone as standard tools can only tell you what the JVM is doing, not the underlying J2EE application. Also, the tools to extract the required detail for the developer are slow, unreliable and as a result, can significantly extend down time. However, the JVM is essentially just another process running on the kernel so our standard tools just may be useful in other ways. As it turns out, they can be used specifically for dumping not the JVM heap, but instead it’s core. This core can then have the JVM heap extracted offline, even on a completely different system! So let’s look at the high-level process and the pre-requisites. Pre-requisites Sufficient disk space for the entire process core (RSS+Shared) Sufficient disk space to hold the extracted heap (usually < RSS+Shared) The GNU Debugger – gdb sudo apt-get install gdb – for Debian/Ubuntu systems. sudo yum install gdb – for RedHat/CentOS systems. The JVM’s process ID (PID) Root (or elevated) privileges to execute arbitrary commands as described below. The Process Summary Get the JVM PID Dump the PID’s core to a file with gdb Extract the JVM Heap from the core file in #2 with jmap Detail First of all, you need to extract the PID for the JVM we need the heap for (pgrep would also work if there was only a single Java application on the host) : ps -ef|grep java # Will output similar to UID PID PPID C STIME TTY TIME CMD 1234 16837 11678 0 Mar13 ? 00:56:51 /usr/lib/jvm/java-7-oracle/bin/java -Djava.util.logging.config.file=/opt/java/tools/tomcat/j2ee-application/conf/logging.properties -server -Xms1024m -Xmx1024m -D -XX:MaxPermSize=256m -Dconfluence.home=.... Now that we have the PID (16837 above) we can tell gdb to dump the core for that process. This stage in the process involves invoking gdb as root (or the application owner) to attach to the PID concerned. Then we want to dump the core to a specific file, detach and quit. You can do all that interactively or batch it (see “Making it better…” below). For now, we’ll assume we’re doing it interactively. NOTE: as soon as you attach the debugger to the process, [...]
Previous Topic
