We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Reliability & Resilience
A visualization of profiled software showing which functions consume the most CPU or wall-clock time. The x-axis is the stack population and the y-axis is call stack depth.
In short
A flame graph is a visualization of profiling data where each box is a function, the width of a box shows how much CPU or wall-clock time that function and everything it called accounted for, and stacked boxes show the call chain that led there. You read width as cost, so the widest boxes are where your program actually spends its time.
In short
A flame graph is a visualization of profiling data where each box is a function, the width of a box shows how much CPU or wall-clock time that function and everything it called accounted for, and stacked boxes show the call chain that led there. You read width as cost, so the widest boxes are where your program actually spends its time.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Flame Graph across a run of lessons, not one page. These 4 alone are about 81 minutes of step-by-step reading, every one with a quiz.
Identify performance bottlenecks in application code. CPU profiling, memory analysis, and flame graphs.
Reduce CPU usage through profiling, algorithm improvement, and concurrency tuning.
Analyze your data to understand its structure, patterns, and anomalies before using or migrating it.
How bug bounty programs pay outside researchers to find security bugs. Compares platforms, shows the report lifecycle, and covers when to launch one.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Application Profilingpay once,
yours for life
A profiler samples your running program many times per second and records the full call stack at each sample. For example, sampling at 99 Hz for 30 seconds gives roughly 2,970 stack snapshots. A flame graph takes all those stacks and merges them into one picture.
Every box is one function. A box sits directly on top of the function that called it, so a vertical stack of boxes is one call chain from the entry point at the bottom up to the function running at the top. The bottom row is usually main or a thread entry point, and the top is whatever was actually on the CPU when the sample was taken.
The width of a box is the only thing that means cost. A box that spans 40 percent of the width was somewhere on the stack in 40 percent of the samples, which means the program spent about 40 percent of its time in that function or its children. Color is normally random and carries no meaning. Left to right ordering is alphabetical or by stack frame, not chronological, so you cannot read time passing from left to right.
Step one is collection. A sampling profiler like Linux perf, async-profiler for the JVM, or py-spy for Python periodically interrupts the process, walks the stack, and writes out each captured stack as a single line of frame names. Sampling is cheap, often under a few percent overhead, which is why it can run on production systems.
Step two is folding. Many identical stacks get collapsed into a count. A stack like main;handleRequest;parseJson seen 600 times becomes one line with the number 600 next to it. Brendan Gregg's original toolkit does this with a stackcollapse script.
Step three is rendering. The folded stacks are turned into a self-contained SVG or an interactive HTML page. Boxes are sized by their sample count relative to the total. Clicking a box zooms so it fills the width, which lets you drill into a hot subtree. There is also the inverted icicle layout, where the root is on top and the graph grows downward, used by Chrome DevTools and many cloud profilers.
Use a flame graph when something is slow or burning CPU and you do not yet know where. It answers the question where is the time going faster than reading code or guessing. It is the standard view in production continuous profilers because a single picture summarizes thousands of stacks.
Pick the right variant for the question. A CPU flame graph (on-CPU) shows where the processor is busy. An off-CPU flame graph shows where threads are blocked waiting on locks, disk, or network, which is invisible in a pure CPU profile. A differential flame graph paints one capture against another in red and blue so you can see what got worse after a deploy.
Be aware of the limits. A flame graph hides time order, so it will not show that a slow function only fires on the first request. Sampling can miss very short or very rare functions. Without symbols, frames show up as raw addresses and the graph is useless, so you need debug symbols and, on the JVM, frame pointers or a profiler that unwinds correctly. It also measures aggregate cost, not a single slow request, so pair it with tracing when you need per-request latency.
Say a Java API server is pinned at 90 percent CPU and p99 latency has doubled. You attach async-profiler for 30 seconds with the command profiler.sh -d 30 -f out.html PID and open the resulting flame graph.
The bottom rows show the request handling threads. Most of the width sits under a single subtree: a JSON serialization library, and inside it a regular expression compile that is being called on every response instead of being cached. That one box is 35 percent of the total width.
You move the regex compilation to a static field so it runs once at startup. After redeploying you capture again, and that 35 percent box has shrunk to under 1 percent, CPU drops, and latency recovers. The flame graph turned a vague this is slow into a precise one line fix.
Netflix
Engineers there, led by Brendan Gregg who created the format, run flame graphs across their fleet to find CPU regressions in JVM and Node services.
Grafana Pyroscope
An open source continuous profiling backend that stores stacks from production services and renders interactive flame graphs over time.
Google Cloud Profiler
Continuously samples CPU, heap, and contention in production and presents the results as flame graphs in the Cloud console.
Chrome DevTools
The Performance panel shows JavaScript execution as a flame chart, the time ordered cousin of the flame graph, to find slow frames and long tasks.
Width is proportional to how often that function appeared on top of the stack across all samples, which approximates how much CPU or wall-clock time it and its children consumed. Wider means more expensive. Width is the only dimension that means cost.
A flame graph merges all samples and orders boxes alphabetically, so the x-axis is total sample count, not time, and identical stacks are combined. A flame chart keeps events in time order along the x-axis, so you can see when each call happened. Chrome DevTools shows flame charts; perf and async-profiler show flame graphs.
It visualizes where threads spend time blocked and off the processor, such as waiting on a lock, disk read, or network call, instead of where the CPU is busy. It is essential for latency problems where the CPU looks idle but requests are still slow.
Missing functions are usually too short or too rare to be caught by sampling. Hex addresses instead of names mean symbols were not available, so install debug symbols, enable frame pointers, or use a runtime aware profiler that can unwind the stack correctly.
Yes. Sampling profilers like Linux perf, async-profiler, and py-spy typically add only a few percent overhead, and continuous profilers such as Pyroscope and Google Cloud Profiler are designed to run safely on live production traffic.
APM
Application Performance Monitoring: tools that track request latency, error rates, and dependencies in real time. Datadog, New Relic, and Grafana are popular APM platforms.
Observability
The ability to understand a system's internal state from its external outputs. Built on three pillars: metrics, logs, and traces.
Distributed Tracing
Tracking a request as it flows through multiple services in a distributed system. Each service adds its trace, creating a full picture of the request journey.
Chaos Engineering
Deliberately injecting failures into a system to test its resilience. Netflix's Chaos Monkey randomly kills servers to ensure the system survives.
Back Pressure
A flow control mechanism where a slow consumer signals upstream producers to slow down. Prevents systems from being overwhelmed by data they can't process.
SLI
Service Level Indicator: a quantitative measure of service behavior, like the proportion of requests faster than 300ms. The raw metric that feeds SLOs.
This page explains the idea. The course covers it step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
See the System Design Masterclass coursecourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Flame Graph in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
