While trying out these examples, I was thinking whether we can generate a CPU Flame Graph from a Java Flight Recording Dump.
Hot Methods and Call Tree tabs in Java Mission Control are there to get an understanding of "hot spots" in your code. But I was really interested to see a Flame Graph visualization by reading the JFR dump. In this way, you can quickly see "hot spots" by using the Flame Graph software.
Even though, this is an easy way, it takes more time and the resulting XML file is quite large. For example, I parsed a JFR dump around 61MB and the XML was around 5.8GB!
Converting JFR Method Profiling Samples to FlameGraph compatible format.
I wrote a simple Java program to read a JFR file and convert all stack traces from "Method Profiling Samples" to FlameGraph compatible format.
I used the JMC Parser in the program. I couldn't find a way to get Method Profiling Samples using the Reference Parser. I was only able to find the "vm/prof/execution_sample" events from the reference parser and there was no way to get the stack trace from that event.
The JMC Parser was very easy to use and I was able to get the stack traces without much trouble.
Following is the FlameGraph created from a sample JFR dump.
I got the JFR dump by running a sample application, which consumes more CPU resources. Original source files were obtained from a StackOverflow answer, which explains a way to find a thread consuming high CPU resources. Please note that the package name and line numbers are different in the FlameGraph output when comparing with original source code in StackOverflow Answer. (I will try to share the complete source code later).
When you are using Java Flight Recorder (JFR), the JFR will use an event settings file to check which event types to record. By default in JFR, there are two settings, "default" and "profile". The default setting is recommended for Continuous Recordings as it has very low overhead (typically less than 1% overhead). The profile setting has more events and useful when profiling the application. As mentioned in my previous blog post regarding Java Flight Recorder Continuous Recordings , we use following arguments to do a Continuous Recording. -XX:+UnlockCommercialFeatures -XX:+FlightRecorder -XX:FlightRecorderOptions=defaultrecording=true,disk=true,repository=./tmp,dumponexit=true,dumponexitpath=./ Note: According to the Oracle documentation on " java " command, we should be able to specify "settings" parameter to the -XX:FlightRecorderOptions. However, the settings parameter has no effect when used with the -XX:FlightRecorderOptions and ...
When we are trying to find performance issues, it is sometimes necessary to do continuous recordings with Java Flight Recorder. Usually we debug issues in an environment similar to a production setup. That means we don't have a desktop environment and we cannot use Java Mission Control for flight recording. That also means we need to record & get dumps using command line in servers. We can of course use remote connection methods, but it's more easier to get recordings from the server. With continuous recordings, we need to figure out how to get dumps. There are few options. Get a dump when the Java application exits. For this, we need to use dumponexit and dumponexitpath options. Get a dump manually from JFR.dump diagnostic command via " jcmd " Note: The "jcmd" command is in $JAVA_HOME/bin. If you use the Oracle Java Installation script for Ubuntu , you can directly use "jcmd" without including $JAVA_HOME/bin in $PATH. Enabl...
Comments