https://huoding.com/2016/08/18/531
很多人感冒發燒的時候，往往會模仿神農氏嘗百草的路子：先嚐嘗抗病毒的藥，再試試抗細菌的藥，甭管家裏有什麼藥挨個試，什麼中藥西藥，瞎貓總會碰上死耗子，如此做法自然是不可取的，正確的做法應該是去醫院驗個血，確診後再對症下藥。
讓我們回想一下我們一般是如何調試程序的：通常是在沒有數據的情況下依靠主觀臆斷來瞎蒙，而不是考慮問題到底是什麼引起的！毫無疑問，調優程序性能問題的時候，同樣需要對症下藥。好消息是 Brendan D. Gregg 發明了火焰圖，可以一針見血的指出程序的性能瓶頸，壞消息是除了 OpenResty 社區，很少看到還有其他人使用火焰圖。
常見的火焰圖類型有 On-CPU，Off-CPU，還有 Memory，Hot/Cold，Differential 等等。下面給出某個 PHP 程序的 On-CPU 類型的火焰圖例子：
Flame Graph
關於火焰圖詳細的介紹可以參考 Blazing Performance with Flame Graphs，簡而言之：整個圖形看起來就像一團跳動的火焰，這也正是其名字的由來。燃燒在火苗尖部的就是 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 被其它進程搶佔了。
在採樣數據的時候，最好通過壓測工具對程序持續施壓，以便採集到足夠的樣本。關於壓測工具的選擇，如果選擇 ab 的話，那麼務必記得開啓 -k 選項，以避免耗盡系統的可用端口。此外，我建議嘗試使用諸如 wrk 之類更現代的壓測工具。
請按照官方說明來安裝。需要着重說明的是，當你安裝 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。
要想熟練的使用火焰圖的話，最好的方法就是多看別人的例子。春哥在微博上發過很多例子，這裏我列舉最具代表性的幾個，版權自然歸春哥所有：
微博來源：通過 Off-CPU 火焰圖可以發現有一個使用互斥鎖的 HTTP Cache 檢查代碼讓絕大部分的 Off-CPU 時間都花在了等待進程鎖上：
微博來源：在移除了那個引發互斥鎖瓶頸的歷史代碼之後，從圖上我們可以清楚地看到 open() 系統調用是下一個最明顯的性能瓶頸：
微博來源：啓用 nginx 的 open_file_cache 指令可以對打開的文件句柄進行緩存，從而節約昂貴的 open() 系統調用。但是緩存容量並不是越大越好，比如當達到 20000 個元素的容量時，共享內存的鎖就成了瓶頸。
如果沒有火焰圖，我們可能會在解決一個問題後引入另一個問題。
實際使用火焰圖的時候，因爲 perf / systemtap 本身對系統性能影響較小，所以我們可以在線上隨時採樣數據來分析性能，我們甚至可以寫一個腳本，自動化定期繪製系統運行狀況的火焰圖，如此一來，即便發生性能故障時我們沒有第一時間在現場，也可以隨時根據火焰圖歷史快照來確診問題的根源。