Flame graphics: “fire” from all engines

Hello everyone again! We invite you to online meeting with Vasily Kudryavtsev (Director of the Quality Assurance Department at RTLabs JSC), which will take place as part of the Load Testing course. And here’s the translation of Michael Hunger – software developer and editor of Neo4j Developer Blog and GRANDstack!

Java standard profilers use either bytecode instrumentation or sampling (by looking at stack traces at short intervals) to determine where time has been spent. Both approaches have their drawbacks and oddities. Understanding the performance of such profilers is an art in itself and requires a lot of experience.

Fortunately, Brendan Gregg, a performance engineer at Netflix, came up with flame charts, a genius-looking stack trace diagram that you can build from almost any system.

The Flame graph sorts and aggregates the traces at each level of the stack, so the number reflects the percentage of the total time spent in that part of the code. Rendering these blocks as rectangles with a width proportional to the percentage of the total running time and stacking them on top of each other proved to be extremely useful visualization. (Note that the order from left to right is not critical, often just alphabetical sorting. Same with colors. Only the relative width and depth of the stack matters)

Flame plot of a benchmark filling in an unallocated ArrayList
Flame plot of a benchmark filling in an unallocated ArrayList

Flames from bottom to top reflect the progression from the entry point of the program or stream (main or event loop) until execution leaves at the ends of the flames.

You will immediately see if some parts of the program take up unexpectedly large amounts of time. The higher you see this in the diagram, the worse. And if you have a very wide flame on top, then you’ve definitely found a bottleneck where the work isn’t delegated elsewhere. After fixing the problem, measure the runtime again, if the performance problem persists, return to the diagram to understand where the problem remains.

To overcome the shortcomings of standard profilers, many modern tools use an internal JVM function (AsyncGetCallTrace), which allows you to collect stack traces independently of safe points. In addition, they combine the measurement of native JVM operations and operating system syscalls, so that time spent on the network, I / O, or garbage collection can also become part of the flame graph.

Tools like Honest Profiler, perf-map-agent, async-profiler, or even IntelliJ IDEA can capture information and make flame plots with ease.

In most cases, you just download the tool, provide the PID of your Java process, and tell the tool to run for a certain period of time and generate an interactive SVG.

# download and unzip async profiler for your OS from:
# https://github.com/jvm-profiling-tools/async-profiler
./profiler.sh -d <duration> -f flamegraph.svg -s -o svg <pid> && 
open flamegraph.svg  -a "Google Chrome"

The SVG generated by these tools is not only colorful but also interactive. You can enlarge sections, search character by character, etc.

Flame charts are an impressive and powerful tool for quickly reviewing the performance characteristics of your programs. With them, you can immediately see bottlenecks and focus on them, and an overview of non-JVM aspects helps to get a fuller picture.


Is it interesting to develop in this direction? Sign up for a free Demo lesson “Scripts and scenarios of load testing – Performance center (PC) and Vugen”!

Similar Posts

Leave a Reply