介紹
perf 是 Linux 2.6.31 以后內置的性能分析工具。它以性能事件采樣為基礎，不僅可以分析系統的各種事件和內核性能，還可以用來分析指定應用程序的性能問題。
使用介紹
perf top
類似於 top，它能夠實時顯示占用 CPU 時鍾最多的函數或者指令，因此可以用來查找熱點函數
$ perf top Samples: 833 of event 'cpu-clock', Event count (approx.): 97742399 Overhead Shared Object Symbol 7.28% perf [.] 0x00000000001f78a4 4.72% [kernel] [k] vsnprintf 4.32% [kernel] [k] module_get_kallsym 3.65% [kernel] [k] _raw_spin_unlock_irqrestore ...
解析：輸出結果中，第一行包含三個數據，分別是采樣數（Samples）、事件類型（event）和事件總數量（Event count）。比如這個例子中，perf 總共采集了 833 個 CPU 時鍾事件，而總事件數則為 97742399。
再往下看是一個表格式樣的數據，每一行包含四列，分別是：
第一列 Overhead ，是該符號的性能事件在所有采樣中的比例，用百分比來表示。
第二列 Shared ，是該函數或指令所在的動態共享對象（Dynamic Shared Object），如內核、進程名、動態鏈接庫名、內核模塊名等。
第三列 Object ，是動態共享對象的類型。比如 [.] 表示用戶空間的可執行程序、或者動態鏈接庫，而 [k] 則表示內核空間。
最后一列 Symbol 是符號名，也就是函數名。當函數名未知時，用十六進制的地址來表示。
Self 是最后一列的符號（可以理解為函數）本身所占比例；
Children 是這個符號調用的其他符號（可以理解為子函數，包括直接和間接調用）占用的比例之和。
perf record 和 perf report
perf top 雖然實時展示了系統的性能信息，但它的缺點是並不保存數據，也就無法用於離線或者后續的分析。而 perf record 則提供了保存數據的功能，保存后的數據，需要你用 perf report 解析展示
$ perf record # 按Ctrl+C終止采樣 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.452 MB perf.data (6093 samples) ] $ perf report # 展示類似於perf top的報告
注意：實際使用中perf top 和 perf record 加上 -g 參數，開啟調用關系的采樣，方便我們根據調用鏈來分析性能問題。
查看指定進程
# -g開啟調用關系分析，-p指定php-fpm的進程號21515 $ perf top -g -p 21566
注意事項
1、有的時候perf 看到的是16進制地址而不是函數名字
原因：很可能是perf 找不到待分析進程依賴的庫，尤其是分析的進程是docker 啟動的，進程依賴的庫也在docker里面，然后perf是在宿主機上面運行的，所以找不到依賴的庫
解決：在容器外面把分析紀錄保存下來，再去容器里查看結果。這樣，庫和符號的路徑也就都對了。比如，你可以這么做。先運行 perf record -g -p < pid>，執行一會兒（比如 15 秒）后，按 Ctrl+C 停止。然后，把生成的 perf.data 文件，拷貝到容器里面來分析
2、perf 的報告中，很多符號都不顯示調用棧
原因：通過man 查詢得知 per 報告中 threshold 的默認值為 0.5%，也就是說，事件比例超過 0.5% 時，調用棧才能被顯示。
解決： perf report -g graph,0.3 #自己設定最低值，如果你的服務進程在0.32左右那么可以設置一個低於0.32的值。
3、性能損耗
perf 它需要在內核中跟蹤內核棧的各種事件，那么不可避免就會帶來一定的性能損失。這一點，雖然對大部分應用來說，沒有太大影響，但對特定的某些應用（比如那些對時鍾周期特別敏感的應用），可能就是災難了。所以，使用性能工具時，確實應該考慮工具本身對系統性能的影響。而這種情況，就需要你了解這些工具的原理。
比如，perf 這種動態追蹤工具，會給系統帶來一定的性能損失。
vmstat、pidstat 這些直接讀取 proc 文件系統來獲取指標的工具，不會帶來性能損失。