Eclipse Mission Control

Reading a Flight Recording

Method sampling

Hunting down code hotspots with JDK Flight Recorder
gives some good pointers.

Why CPU usage is important

I mention what CPU metrics are important during profiling with JDK Flight Recorder.
If we look at Java thread at any given time, it could be

  1. running on CPU in Java code
  2. ready to run in Java code but waiting in OS queue to get CPU
  3. running on CPU in native (non-Java) code
  4. ready to run in native code but waiting in OS queue to get CPU
  5. waiting to do something in native non-Java code
  6. waiting/blocked at the Java level

JFR samples only threads in categories 1 or 2. There are also separate sampling for 3, 4 and 5, which is not well exposed in any dedicated report in Mission Control at the time of writing.
So, if your server is starving on CPU, JFR will show you a particular picture, but it would be skewed due to mixing 1 and 2 categories. Sampling picture and would not accurately reflect real code computation cost in this situation.
If the server is not CPU starved and threads you are profiling are actively consuming CPU, method sampling is the right tool for you to start with.
If the server is not CPU starved and threads you are profiling are low on CPU, you are likely to have a “cold” hotspot, falling into categories 5 and 6.
Category 5 code you can analyze with the “Native method sampling” event.
Category 6 is either contention or IO, examined with separate reports.
So by looking at CPU, you get an idea which report would be most useful next.