本文主要分享火焰圖使用技巧，介紹 systemtap 的原理機制，如何使用火焰圖快速定位效能問題原因，同時加深對 systemtap 的理解。
讓我們回想一下，曾經作為程式設計新手的我們是如何調優程式的？通常是在沒有資料的情況下依靠主觀臆斷來瞎蒙，稍微有些經驗的同學則會對差異程式碼進行二分或者逐段除錯。這種定位問題的方式不僅耗時耗力，而且還不具有通用性，當遇到其他類似的效能問題時，需要重複踩坑、填坑，那麼如何避免這種情況呢？
俗語有曰：兵慾善其事必先利其器，個人認為，程式設計師定位效能問題也需要一件“利器”。如同醫生給病人看病，需要依靠專業的醫學工具（比如 X 光片、聽診器等）進行診斷，最後依據醫學工具的檢驗結果快速精準的定位出病因所在。效能調優工具（比如 perf / gprof 等）之於效能調優就像 X 光之於病人一樣，它可以一針見血的指出程式的效能瓶頸。
但是常用的效能調優工具 perf 等，在呈現內容上只能單一的列出呼叫棧或者非層次化的時間分佈，不夠直觀。這裡我推薦大家配合使用火焰圖，它將 perf 等工具採集的資料呈現得更為直觀。
初識火焰圖
火焰圖（Flame Graph）是由 Linux 效能最佳化大師 Brendan Gregg 發明的，和所有其他的 profiling 方法不同的是，火焰圖以一個全域性的視野來看待時間分佈，它從底部往頂部，列出所有可能導致效能瓶頸的呼叫棧。
火焰圖整個圖形看起來就像一個跳動的火焰，這就是它名字的由來。
火焰圖有以下特徵（這裡以 on-cpu 火焰圖為例）：
每一列代表一個呼叫棧，每一個格子代表一個函式 縱軸展示了棧的深度，按照呼叫關係從下到上排列。最頂上格子代表取樣時，正在佔用 cpu 的函式。 橫軸的意義是指：火焰圖將採集的多個呼叫棧資訊，透過按字母橫向排序的方式將眾多資訊聚合在一起。需要注意的是它並不代表時間。 橫軸格子的寬度代表其在取樣中出現頻率，所以一個格子的寬度越大，說明它是瓶頸原因的可能性就越大。 火焰圖格子的顏色是隨機的暖色調，方便區分各個呼叫資訊。 其他的取樣方式也可以使用火焰圖， on-cpu 火焰圖橫軸是指 cpu 佔用時間，off-cpu 火焰圖橫軸則代表阻塞時間。 取樣可以是單執行緒、多執行緒、多程序甚至是多 host，進階用法可以參考附錄進階閱讀。
火焰圖型別
常見的火焰圖型別有 On-CPU，Off-CPU，還有 Memory，Hot/Cold，Differential 等等。他們分別適合處理什麼樣的問題呢？
這裡筆者主要使用到的是 On-CPU、Off-CPU 以及 Memory 火焰圖，所以這裡僅僅對這三種火焰圖作比較，也歡迎大家補充和斧正。
火焰圖分析技巧
縱軸代表呼叫棧的深度（棧楨數），用於表示函式間呼叫關係：下面的函式是上面函式的父函式。 橫軸代表呼叫頻次，一個格子的寬度越大，越說明其可能是瓶頸原因。 不同型別火焰圖適合最佳化的場景不同，比如 on-cpu 火焰圖適合分析 cpu 佔用高的問題函式，off-cpu 火焰圖適合解決阻塞和鎖搶佔問題。 無意義的事情：橫向先後順序是為了聚合，跟函式間依賴或呼叫關係無關；火焰圖各種顏色是為方便區分，本身不具有特殊含義 多練習：進行效能最佳化有意識的使用火焰圖的方式進行效能調優（如果時間充裕）
如何繪製火焰圖？
要生成火焰圖，必須要有一個順手的動態追蹤工具，如果作業系統是 Linux 的話，那麼通常通常是 perf 或者 systemtap 中的一種。其中 perf 相對更常用，多數 Linux 都包含了 perf 這個工具，可以直接使用；SystemTap 則功能更為強大，監控也更為靈活。網上關於如何使用 perf 繪製火焰圖的文章非常多而且豐富，所以本文將以 SystemTap 為例。
SystemTap 是動態追蹤工具，它透過探針機制，來採集核心或者應用程式的執行資訊，從而可以不用修改核心和應用程式的程式碼，就獲得豐富的資訊，幫你分析、定位想要排查的問題。SystemTap 定義了一種類似的 DSL 指令碼語言，方便使用者根據需要自由擴充套件。不過，不同於動態追蹤的鼻祖 DTrace ，SystemTap 並沒有常駐核心的執行時，它需要先把指令碼編譯為核心模組，然後再插入到核心中執行。這也導致 SystemTap 啟動比較緩慢，並且依賴於完整的除錯符號表。
使用 SystemTap 繪製火焰圖的主要流程如下：
安裝 SystemTap 以及 作業系統符號除錯表 根據自己所需繪製的火焰圖型別以及程序型別選擇合適的指令碼 生成核心模組 執行 SystemTap 或者執行生成的核心模組統計資料 將統計資料轉換成火焰圖
本文演示步驟將會基於作業系統 Tlinux 2.2
安裝 SystemTap 以及 作業系統符號除錯表
使用 yum 工具安裝 systemtap:
yum install systemtap systemtap-runtime
由於 systemtap 工具依賴於完整的除錯符號表，而且生產環境不同機器的核心版本不同（雖然都是Tlinux 2.2版本，但是核心版本後面的小版本不一樣，可以透過 uname -a 命令檢視）所以我們還需要安裝 kernel-debuginfo 包、 kernel-devel 包 我這裡是安裝了這兩個依賴包
kernel-devel-3.10.107-1-tlinux2-0046.x86_64
kernel-debuginfo-3.10.107-1-tlinux2-0046.x86_64
根據自己所需繪製的火焰圖型別以及程序型別選擇合適的指令碼
使用 SystemTap 統計相關資料往往需要自己依照它的語法，編寫指令碼，具有一定門檻。幸運的是，github 上春哥（agentzh）開源了兩組他常用的 SystemTap 指令碼：openresty-systemtap-toolkit 和 stapxx，這兩個工具集能夠覆蓋大部分 C 程序、nginx 程序以及 Openresty 程序的效能問題場景。
我們這裡需要繪製 off-cpu 火焰圖，所以使用 sample-bt-off-cpu 指令碼即可
生成核心模組
現在我們有了統計指令碼，也安裝好了 systemtap，正常來說就可以使用了，但由於 systemtap 是透過生成核心模組的方式統計相關探針的統計資料，而 tlinux 要求所有執行的核心模組需要先到 tlinux 平臺簽名才可以執行，所以：
故需要先修改 off-cpu 指令碼，讓其先生成核心模組；之後對該核心模組作簽名；最後使用 systemtap 命令手工執行該指令碼，統計監控資料
Systemtap 執行流程如下：
parse：分析指令碼語法 elaborate：展開指令碼 中定義的探針和連線預定義指令碼庫，分析核心和核心模組的除錯資訊 translate：.將指令碼編譯成c語言核心模組檔案放 在$HOME/xxx.c 快取起來，避免同一指令碼多次編譯 build：將c語言模組檔案編譯成.ko的核心模組，也快取起來。 把模組交給staprun，staprun載入核心模組到核心空間,stapio連線核心模組和使用者空間，提供互動IO通道,採集資料。
所以我們這裡修改下 off-cpu 的 stap 指令碼，讓其只執行完第四階段，只生成一個核心模組
// 在 stap 命令後增加 -p4 引數，告訴systemtap，當前只需要執行到第四階段
open my $in, "|stap -p4 --skip-badvars --all-modules -x $pid -d '$exec_path' --ldd $d_so_args $stap_args -"
or die "Cannot run stap: $!\n";
修改好之後執行指令碼，會生成一個核心模組
// -p 8682 是需要監控的程序的程序號
// -t 30 是指會取樣30秒
./sample-bt-off-cpu -p 8692 -t 30
生成的核心模組名稱形如 stap_xxxxx.ko模組名稱 由於讀者並不需要關心核心模組簽名，故章節略過
執行核心模組統計資料
核心模組簽名完成後，便可以使用 staprun 命令手工執行相關核心模組了
命令：
// 注意：簽名指令碼會將生產的核心模組重新命名，需要將名字改回去……（指令碼bug）
staprun -x {程序號} {核心模組名} > demo.bt
值得注意的是，監控的程序要有一定負載 systemtap 才可以採集到相關資料，即在採集時，同時需要要有一定請求量（通常是自己構造請求，壓測程序）
將統計資料轉換成火焰圖
獲得了統計資料 demo.bt 後，便可以使用火焰圖工具繪製火焰圖了
下載 FlameGraph，連結：
https://github.com/brendangregg/FlameGraph
命令：
./stackcollapse-stap.pl demo.bt > demo.folded
./flamegraph.pl demo.folded > demo.svg
這樣便獲得了 off-cpu 火焰圖：
看圖說話
趁熱打鐵，透過幾張火焰圖熟悉下如何使用火焰圖
圖片來自於春哥微博或者個人近期定位的問題
on-cpu 火焰圖
Apache APISIX QPS急劇下降問題
Apache APISIX 是一個開源國產的高效能 API 閘道器，之前在進行選型壓測時，發現當 Route 匹配不中場景下， QPS 急劇下降，在其 CPU （四十八核）佔用率幾乎達到100%的情況下只有幾千 QPS，透過繪製火焰圖發現，其主要耗時在一個 table 插入階段(lj_cf_table_insert)，分析程式碼發現是該 table 一直沒有釋放，每次匹配不中路由會插入資料，導致表越來越大，後續插入耗時過長導致 QPS 下降。
off-cpu 火焰圖
nginx 互斥鎖問題
這是一張 nginx 的 off-cpu 火焰圖，我們可以很快鎖定到 ngx_common_set_cache_fs_size -> ngx_shmtx_lock -> sem_wait 這段邏輯使用到了互斥鎖，它讓 nginx 程序絕大部分阻塞等待時間花費在獲取該鎖。
agent 監控上報斷點問題
這是一張 agent 的 off-cpu 火焰圖，它是一個多執行緒非同步事件模型，主執行緒處理各個訊息，多個執行緒分別負責配置下發或者監控上報的職責。當前問題出現在監控上報效能差，無法在週期（一分鐘）內完成監控資料上報，導致監控斷點，透過 off-cpu 火焰圖我們可以分析出，該上報執行緒花費了大量的時間使用 curl_easy_perform 介面收發 http 監控資料訊息中。
依據火焰圖將傳送 http 訊息的邏輯改為非同步非阻塞後，該問題解決。
附錄
進階閱讀
谷歌搜尋演講：Blazing Performance with Flame Graphs 演講 ppt：https://www.slideshare.net/brendangregg/blazing-performance-with-flame-graphs 《SystemTap新手指南》：https://spacewander.gitbooks.io/systemtapbeginnersguide_zh/content/index.html
FAQ
使用 perf 或者 systemtap 的方式採集資料，會對後臺服務有效能影響嗎？
有，但是很小，可以基本忽略不計。
它們使用系統的探針或者使用一些自定義的動態探針進行資料採集，第一對程式碼無侵入性，它既不需要停止服務，也不需要修改應用程式的程式碼；第二，它們是以核心模組/核心原生的方式跟蹤使用者態和核心態的所有事件，並透過一系列最佳化措施，進行取樣統計，對目標服務效能影響極小，大概在5%左右或者更低的效能損耗。相較於將程序執行在沙箱的 valgrind 工具或靜態除錯工具 gdb 來說，動態追蹤 perf 或者 systemtap 或者 ebpf 的效能損耗基本可以忽略不計。
目標程序重啟後，systemtap 是否需要重新生成核心模組？
不需要。甚至同一個 linux 核心版本下的同一個二進位制程序（md5值一致），在安裝 kernel 除錯符號表後，便可以在生成採集指標的核心模組，並且可以多次使用。
當 linux 核心版本不一致，符號表有變化，需要重新生成核心模組；當目標程序二進位制檔案重新編譯後，也需要重新生成統計用的 systemtap 核心模組。
