轉(zhuǎn)自：https://huoding.com/2016/08/18/531
很多人感冒發(fā)燒的時候拣宰，往往會模仿神農(nóng)氏嘗百草的路子：先嘗嘗抗病毒的藥帜慢，再試試抗細(xì)菌的藥瘦真，甭管家里有什么藥挨個試莫湘，什么中藥西藥倾鲫，瞎貓總會碰上死耗子，如此做法自然是不可取的，正確的做法應(yīng)該是去醫(yī)院驗個血揽乱，確診后再對癥下藥。
讓我們回想一下我們一般是如何調(diào)試程序的：通常是在沒有數(shù)據(jù)的情況下依靠主觀臆斷來瞎蒙壤追，而不是考慮問題到底是什么引起的！毫無疑問供屉，調(diào)優(yōu)程序性能問題的時候行冰，同樣需要對癥下藥。好消息是 Brendan D. Gregg 發(fā)明了火焰圖伶丐，可以一針見血的指出程序的性能瓶頸悼做，壞消息是除了 OpenResty社區(qū)，很少看到還有其他人使用火焰圖哗魂。
常見的火焰圖類型有 On-CPU肛走，Off-CPU，還有 Memory录别，Hot/Cold朽色，Differential 等等。下面給出某個 PHP 程序的 On-CPU 類型的火焰圖例子：
關(guān)于火焰圖詳細(xì)的介紹可以參考 Blazing Performance with Flame Graphs组题，簡而言之：整個圖形看起來就像一團跳動的火焰葫男，這也正是其名字的由來。燃燒在火苗尖部的就是 CPU 正在執(zhí)行的操作崔列，不過需要說明的是顏色是隨機的梢褐，本身并沒有特殊的含義，縱向表示調(diào)用棧的深度赵讯，橫向表示消耗的時間盈咳。因為調(diào)用棧在橫向會按照字母排序，并且同樣的調(diào)用棧會做合并瘦癌，所以一個格子的寬度越大越說明其可能是瓶頸猪贪。綜上所述，主要就是看那些比較寬大的火苗讯私，特別留意那些類似平頂山的火苗。
要生成火焰圖西傀，必須要有一個順手的 Tracer 工具斤寇，如果操作系統(tǒng)是 Linux 的話，那么選擇通常是 perf拥褂，systemtap 中的一種娘锁。其中 perf 相對更常用，多數(shù) Linux 都包含了它饺鹃，有興趣的讀者稍后可以參考 Linux Profiling at Netflix中的介紹莫秆，尤其是里面關(guān)于如何處理 Broken stacks 問題的描述间雀，建議多看幾遍，而 systemtap 相對更強大镊屎，不過缺點是你需要先學(xué)會它本身的編程語言惹挟，如果你和我一樣覺得麻煩，那么我強烈推薦你使用春哥的 nginx-systemtap-toolkit缝驳，乍一看名字你可能會誤以為這個工具包是 nginx 專用的连锯，實際上這里面很多工具適用于任何 C/CPP 語言編寫的程序：
sample-bt：用來生成 On-CPU 火焰圖的采樣數(shù)據(jù)（DEMO）
sample-bt-off-cpu：用來生成 Off-CPU 火焰圖的采樣數(shù)據(jù)（DEMO）
那么什么時候使用 On-CPU 火焰圖？什么時候使用 Off-CPU 火焰圖呢用狱？取決于當(dāng)前的瓶頸到底是什么运怖，如果是 CPU 則使用 On-CPU 火焰圖，如果是 IO 或鎖 則使用 Off-CPU 火焰圖夏伊。如果無法確定摇展，那么可以通過壓測工具來確認(rèn)：通過壓測工具看看能否讓 CPU 使用率趨于飽和，如果能那么使用 On-CPU 火焰圖溺忧，如果不管怎么壓咏连，CPU 使用率始終上不來，那么多半說明程序被 IO 或鎖卡住了砸狞，此時適合使用 Off-CPU 火焰圖捻勉。如果還是確認(rèn)不了，那么不妨 On-CPU 火焰圖和 Off-CPU 火焰圖都搞搞刀森，正常情況下它們的差異會比較大踱启，如果兩張火焰圖長得差不多，那么通常認(rèn)為 CPU 被其它進(jìn)程搶占了研底。
在采樣數(shù)據(jù)的時候埠偿，最好通過壓測工具對程序持續(xù)施壓，以便采集到足夠的樣本榜晦。關(guān)于壓測工具的選擇冠蒋，如果選擇 ab 的話，那么務(wù)必記得開啟 -k 選項乾胶，以避免耗盡系統(tǒng)的可用端口抖剿。此外，我建議嘗試使用諸如 wrk 之類更現(xiàn)代的壓測工具识窿。
請按照官方說明來安裝斩郎。需要著重說明的是，當(dāng)你安裝 kernel-devel 和 kernel-debuginfo 的時候喻频，務(wù)必保證所安裝的版本和當(dāng)前內(nèi)核版本一致缩宜，以 CentOS 為例：
shell> yum install yum-utilsshell> yum install kernel-develshell> debuginfo-install kernel
當(dāng)生成的火焰圖中有很多十六進(jìn)制的亂碼時，那么意味著對應(yīng)程序缺失了 debuginfo，可以借助 gdb 來確認(rèn)這一點锻煌，方法如下所示：
shell> gdb -p <PID>
好消息是如果缺失了某些 debuginfo妓布，那么 gdb 會在結(jié)尾提示你用 debuginfo-install 命令來安裝，壞消息是如果你直接運行多半沒有效果宋梧，因為 CentOS 缺省沒有激活對應(yīng)的倉庫匣沼，所以需要在「/etc/yum.repos.d/CentOS-Debuginfo.repo」中設(shè)置 enabled=1。
要想熟練的使用火焰圖的話乃秀，最好的方法就是多看別人的例子肛著。春哥在微博上發(fā)過很多例子，這里我列舉最具代表性的幾個跺讯，版權(quán)自然歸春哥所有：
微博來源：通過 Off-CPU 火焰圖可以發(fā)現(xiàn)有一個使用互斥鎖的 HTTP Cache 檢查代碼讓絕大部分的 Off-CPU 時間都花在了等待進(jìn)程鎖上：
微博來源：在移除了那個引發(fā)互斥鎖瓶頸的歷史代碼之后枢贿，從圖上我們可以清楚地看到 open() 系統(tǒng)調(diào)用是下一個最明顯的性能瓶頸：
微博來源：啟用 nginx 的 open_file_cache 指令可以對打開的文件句柄進(jìn)行緩存，從而節(jié)約昂貴的 open() 系統(tǒng)調(diào)用刀脏。但是緩存容量并不是越大越好局荚，比如當(dāng)達(dá)到 20000 個元素的容量時，共享內(nèi)存的鎖就成了瓶頸愈污。
如果沒有火焰圖耀态，我們可能會在解決一個問題后引入另一個問題。
實際使用火焰圖的時候暂雹，因為 perf / systemtap 本身對系統(tǒng)性能影響較小首装，所以我們可以在線上隨時采樣數(shù)據(jù)來分析性能，我們甚至可以寫一個腳本杭跪，自動化定期繪制系統(tǒng)運行狀況的火焰圖仙逻，如此一來，即便發(fā)生性能故障時我們沒有第一時間在現(xiàn)場涧尿，也可以隨時根據(jù)火焰圖歷史快照來確診問題的根源系奉。
