Brendan D. Gregg 發明了火焰圖，可以一針見血的指出程序的性能瓶頸，壞消息是除了OpenResty 社區，很少看到還有其他人使用火焰圖。
常見的火焰圖類型有 On-CPU，Off-CPU，還有 Memory，Hot/Cold，Differential 等等。
整個圖形看起來就像一團跳動的火焰，這也正是其名字的由來。燃燒在火苗尖部的就是 CPU 正在執行的操作，不過需要說明的是顏色是隨機的，本身並沒有特殊的含義，縱向表示調用棧的深度，橫向表示消耗的時間。因為調用棧在橫向會按照字母排序，並且同樣的調用棧會做合並，所以一個格子的寬度越大越說明其可能是瓶頸。綜上所述，主要就是看那些比較寬大的火苗，特別留意那些類似平頂山的火苗。
要生成火焰圖，必須要有一個順手的 Tracer 工具，如果操作系統是 Linux 的話，那么選擇通常是 perf，systemtap 中的一種。其中 perf 相對更常用，多數 Linux 都包含了它，有興趣的讀者稍后可以參考 Linux Profiling at Netflix 中的介紹，尤其是里面關於如何處理 Broken stacks 問題的描述，建議多看幾遍，而 systemtap 相對更強大，不過缺點是你需要先學會它本身的編程語言，如果你和我一樣覺得麻煩，那么我強烈推薦你使用春哥的 nginx-systemtap-toolkit，乍一看名字你可能會誤以為這個工具包是 nginx 專用的，實際上這里面很多工具適用於任何 C/CPP 語言編寫的程序：
- sample-bt：用來生成 On-CPU 火焰圖的采樣數據（DEMO）
- sample-bt-off-cpu：用來生成 Off-CPU 火焰圖的采樣數據（DEMO）
那么什么時候使用 On-CPU 火焰圖？什么時候使用 Off-CPU 火焰圖呢？取決於當前的瓶頸到底是什么，如果是 CPU 則使用 On-CPU 火焰圖，如果是 IO 或鎖 則使用 Off-CPU 火焰圖。如果無法確定，那么可以通過壓測工具來確認：通過壓測工具看看能否讓 CPU 使用率趨於飽和，如果能那么使用 On-CPU 火焰圖，如果不管怎么壓，CPU 使用率始終上不來，那么多半說明程序被 IO 或鎖卡住了，此時適合使用 Off-CPU 火焰圖。如果還是確認不了，那么不妨 On-CPU 火焰圖和 Off-CPU 火焰圖都搞搞，正常情況下它們的差異會比較大，如果兩張火焰圖長得差不多，那么通常認為 CPU 被其它進程搶占了。
請按照官方說明來安裝。需要着重說明的是，當你安裝 kernel-devel 和 kernel-debuginfo 的時候，務必保證所安裝的版本和當前內核版本一致，以 CentOS 為例：
shell> yum install yum-utils shell> yum install kernel-devel shell> debuginfo-install kernel
當生成的火焰圖中有很多十六進制的亂碼時，那么意味着對應程序缺失了 debuginfo，可以借助 gdb 來確認這一點，方法如下所示：
shell> gdb -p <PID>
好消息是如果缺失了某些 debuginfo，那么 gdb 會在結尾提示你用 debuginfo-install 命令來安裝，壞消息是如果你直接運行多半沒有效果，因為 CentOS 缺省沒有激活對應的倉庫，所以需要在「/etc/yum.repos.d/CentOS-Debuginfo.repo」中設置 enabled=1。
FlameGraph代碼：https://github.com/cobblau/FlameGraph
使用方法
1，perf record --call-graph dwarf -p 12345
2，perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > process.svg
使用其他工具如何生成火焰圖的方法在FlameGraph的Readme只有詳細的介紹
上面圖片中，最頂層的函數g()占用 CPU 時間最多。d()的寬度最大，但是它直接耗用 CPU 的部分很少。b()和c()沒有直接消耗 CPU。因此，如果要調查性能問題，首先應該調查g()，其次是i()。
另外，從圖中可知a()有兩個分支b()和h()，這表明a()里面可能有一個條件語句，而b()分支消耗的 CPU 大大高於h()。