I'm starting JFR at launch by specifying the following CLI options to the Java program under test:
-Xmx24g -XX:+UnlockCommercialFeatures -XX:+FlightRecorder
-XX:FlightRecorderOptions=defaultrecording=true,dumponexit=true,settings=profile
The test execution takes 90 seconds to complete.
After opening the JFR dump in Java Mission Control, the Call Tree tab in JMC looks like this:
There is less than 1 sample per second. That makes the detail drill-down, Hot Methods and Overview tabs effectively useless. After initial investigation it was determined the method sampling is set to the default of 10ms, and, as it turns out, this unexpected result is because ~98% of the 90 seconds are spent waiting on socket I/O while performing various different database reads, so I'm only getting method samples for the other ~2% of the time.
How can I include I/O-bound samples in the method time, in order to help locate the trace that's spending the most time waiting for database results? The process contains database queries in multiple places, which in turn are called from multiple other places, so guessing at the slow call path is not easy.
The lowest method execution sampling rate on JDK 8 is 10 ms, which is what you get with profile settings. This should be more than sufficient for a 90 seconds recording, assuming there is load on the application. There was a bug in JDK 11 that lead to too few samples, but I can see from the screenshot you are running an earlier release.
If you want to know what the application is doing when it is waiting, you should look at the Latency tab (not Hot Methods) or Socket Read / Socket Write tabs. There are events for Socket Read, Socket Write, Monitor Blocked, Monitor Wait etc., but may not apply if you are using async I/O.
EDIT
