運維必殺技Perf — Linux下的系統效能調優工具

說明一個工具的最佳途徑是列舉一個例子。

考查下麵這個例子程式。其中函式 longa() 是個很長的迴圈，比較浪費時間。函式 foo1 和 foo2 將分別呼叫該函式 10 次，以及 100 次。

清單 1. 測試程式 t1

//test.c 
 void longa() 
 { 
   int i,j; 
   for(i = 0; i < 1000000; i++) 
   j=i; //am I silly or crazy? I feel boring and desperate. 
 } 
 void foo2() 
 { 
   int i; 
   for(i=0 ; i < 10; i++) 
        longa(); 
 } 
 void foo1() 
 { 
   int i; 
   for(i = 0; i< 100; i++) 
      longa(); 
 } 

 int main(void) 
 { 
   foo1(); 
   foo2(); 
 }

找到這個程式的效能瓶頸無需任何工具，肉眼的閱讀便可以完成。Longa() 是這個程式的關鍵，只要提高它的速度，就可以極大地提高整個程式的執行效率。

但，因為其簡單，卻正好可以用來演示 perf 的基本使用。假如 perf 告訴您這個程式的瓶頸在別處，您就不必再浪費寶貴時間閱讀本文了。

它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者補丁分支（hotfix branch）。完成開發後，該分支就合併到主分支，然後被刪除。

準備使用 perf

安裝 perf 非常簡單，只要您有 2.6.31 以上的核心原始碼，那麼進入 tools/perf 目錄然後敲入下麵兩個命令即可：

make 
 make install

效能調優工具如 perf，Oprofile 等的基本原理都是對被監測物件進行取樣，最簡單的情形是根據 tick 中斷進行取樣，即在 tick 中斷內觸發取樣點，在取樣點裡判斷程式當時的背景關係。假如一個程式 90% 的時間都花費在函式 foo() 上，那麼 90% 的取樣點都應該落在函式 foo() 的背景關係中。運氣不可捉摸，但我想只要取樣頻率足夠高，取樣時間足夠長，那麼以上推論就比較可靠。因此，透過 tick 觸發取樣，我們便可以瞭解程式中哪些地方最耗時間，從而重點分析。

稍微擴充套件一下思路，就可以發現改變取樣的觸發條件使得我們可以獲得不同的統計資料：

以時間點 ( 如 tick) 作為事件觸發取樣便可以獲知程式執行時間的分佈。

以 cache miss 事件觸發取樣便可以知道 cache miss 的分佈，即 cache 失效經常發生在哪些程式程式碼中。如此等等。

因此讓我們先來瞭解一下 perf 中能夠觸發取樣的事件有哪些。

它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者補丁分支（hotfix branch）。完成開發後，該分支就合併到主分支，然後被刪除。

Perf list，perf 事件

使用 perf list 命令可以列出所有能夠觸發 perf 取樣點的事件。比如

$ perf list 
 List of pre-defined events (to be used in -e): 
 cpu-cycles OR cycles [Hardware event] 
 instructions [Hardware event] 
…
 cpu-clock [Software event] 
 task-clock [Software event] 
 context-switches OR cs [Software event] 
…
 ext4:ext4_allocate_inode [Tracepoint event] 
 kmem:kmalloc [Tracepoint event] 
 module:module_load [Tracepoint event] 
 workqueue:workqueue_execution [Tracepoint event] 
 sched:sched_{wakeup,switch} [Tracepoint event] 
 syscalls:sys_{enter,exit}_epoll_wait [Tracepoint event] 
…

不同的系統會列出不同的結果，在 2.6.35 版本的核心中，該串列已經相當的長，但無論有多少，我們可以將它們劃分為三類：

Hardware Event 是由 PMU 硬體產生的事件，比如 cache 命中，當您需要瞭解程式對硬體特性的使用情況時，便需要對這些事件進行取樣；

Software Event 是核心軟體產生的事件，比如行程切換，tick 數等 ;

Tracepoint event 是核心中的靜態 tracepoint 所觸發的事件，這些 tracepoint 用來判斷程式執行期間內核的行為細節，比如 slab 分配器的分配次數等。

上述每一個事件都可以用於取樣，並生成一項統計資料，時至今日，尚沒有檔案對每一個 event 的含義進行詳細解釋。我希望能和大家一起努力，以弄明白更多的 event 為標的。。。

它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者補丁分支（hotfix branch）。完成開發後，該分支就合併到主分支，然後被刪除。

Perf stat

做任何事都最好有條有理。老手往往能夠做到不慌不忙，循序漸進，而新手則往往東一下，西一下，不知所措。

面對一個問題程式，最好採用自頂向下的策略。先整體看看該程式執行時各種統計事件的大概，再針對某些方向深入細節。而不要一下子扎進瑣碎細節，會一葉障目的。

有些程式慢是因為計算量太大，其多數時間都應該在使用 CPU 進行計算，這叫做 CPU bound 型；有些程式慢是因為過多的 IO，這種時候其 CPU 利用率應該不高，這叫做 IO bound 型；對於 CPU bound 程式的調優和 IO bound 的調優是不同的。

如果您認同這些說法的話，Perf stat 應該是您最先使用的一個工具。它透過概括精簡的方式提供被除錯程式執行的整體情況和彙總資料。

還記得我們前面準備的那個例子程式麼？現在將它編譯為可執行檔案 t1

gcc – o t1 – g test.c

下麵演示了 perf stat 針對程式 t1 的輸出：

$perf stat ./t1 
 Performance counter stats for './t1': 
 262.738415 task-clock-msecs # 0.991 CPUs 
 2 context-switches # 0.000 M/sec 
 1 CPU-migrations # 0.000 M/sec 
 81 page-faults # 0.000 M/sec 
 9478851 cycles # 36.077 M/sec (scaled from 98.24%) 
 6771 instructions # 0.001 IPC (scaled from 98.99%) 
 111114049 branches # 422.908 M/sec (scaled from 99.37%) 
 8495 branch-misses # 0.008 % (scaled from 95.91%) 
 12152161 cache-references # 46.252 M/sec (scaled from 96.16%) 
 7245338 cache-misses # 27.576 M/sec (scaled from 95.49%) 
  0.265238069 seconds time elapsed 
上面告訴我們，程式 t1 是一個 CPU bound 型，因為 task-clock-msecs 接近 1。

對 t1 進行調優應該要找到熱點 ( 即最耗時的程式碼片段 )，再看看是否能夠提高熱點程式碼的效率。

預設情況下，除了 task-clock-msecs 之外，perf stat 還給出了其他幾個最常用的統計資訊：

Task-clock-msecs：CPU 利用率，該值高，說明程式的多數時間花費在 CPU 計算上而非 IO。

Context-switches：行程切換次數，記錄了程式執行過程中發生了多少次行程切換，頻繁的行程切換是應該避免的。

Cache-misses：程式執行過程中總體的 cache 利用情況，如果該值過高，說明程式的 cache 利用不好

CPU-migrations：表示行程 t1 執行過程中發生了多少次 CPU 遷移，即被排程器從一個 CPU 轉移到另外一個 CPU 上執行。

Cycles：處理器時鐘，一條機器指令可能需要多個 cycles，

Instructions: 機器指令數目。

IPC：是 Instructions/Cycles 的比值，該值越大越好，說明程式充分利用了處理器的特性。

Cache-references: cache 命中的次數

Cache-misses: cache 失效的次數。

透過指定 -e 選項，您可以改變 perf stat 的預設事件 ( 關於事件，在上一小節已經說明，可以透過 perf list 來檢視 )。假如您已經有很多的調優經驗，可能會使用 -e 選項來檢視您所感興趣的特殊的事件。

它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者補丁分支（hotfix branch）。完成開發後，該分支就合併到主分支，然後被刪除。

perf Top

使用 perf stat 的時候，往往您已經有一個調優的標的。比如我剛才寫的那個無聊程式 t1。

也有些時候，您只是發現系統效能無端下降，並不清楚究竟哪個行程成為了貪吃的 hog。

此時需要一個類似 top 的命令，列出所有值得懷疑的行程，從中找到需要進一步審查的傢伙。類似法制節目中辦案民警常常做的那樣，透過檢視監控錄影從茫茫人海中找到行為古怪的那些人，而不是到大街上抓住每一個人來審問。

Perf top 用於實時顯示當前系統的效能統計資訊。該命令主要用來觀察整個系統當前的狀態，比如可以透過檢視該命令的輸出來檢視當前系統最耗時的核心函式或某個使用者行程。

讓我們再設計一個例子來演示吧。

不知道您怎麼想，反正我覺得做一件有益的事情很難，但做點兒壞事兒卻非常容易。我很快就想到瞭如程式碼清單 2 所示的一個程式：

清單 2. 一個死迴圈

while (1) i++;

我叫他 t2。啟動 t2，然後用 perf top 來觀察：

下麵是 perf top 的可能輸出：

PerfTop: 705 irqs/sec kernel:60.4% [1000Hz cycles] 
 -------------------------------------------------- 
 sampl pcnt function DSO 
 1503.00 49.2% t2 
 72.00 2.2% pthread_mutex_lock /lib/libpthread-2.12.so 
 68.00 2.1% delay_tsc [kernel.kallsyms] 
 55.00 1.7% aes_dec_blk [aes_i586] 
 55.00 1.7% drm_clflush_pages [drm] 
 52.00 1.6% system_call [kernel.kallsyms] 
 49.00 1.5% __memcpy_ssse3 /lib/libc-2.12.so 
 48.00 1.4% __strstr_ia32 /lib/libc-2.12.so 
 46.00 1.4% unix_poll [kernel.kallsyms] 
 42.00 1.3% __ieee754_pow /lib/libm-2.12.so 
 41.00 1.2% do_select [kernel.kallsyms] 
 40.00 1.2% pixman_rasterize_edges libpixman-1.so.0.18.0 
 37.00 1.1% _raw_spin_lock_irqsave [kernel.kallsyms] 
 36.00 1.1% _int_malloc /lib/libc-2.12.so 
 ^C

很容易便發現 t2 是需要關註的可疑程式。不過其作案手法太簡單：肆無忌憚地浪費著 CPU。所以我們不用再做什麼其他的事情便可以找到問題所在。但現實生活中，影響效能的程式一般都不會如此愚蠢，所以我們往往還需要使用其他的 perf 工具進一步分析。

透過新增 -e 選項，您可以列出造成其他事件的 TopN 個行程 / 函式。比如 -e cache-miss，用來看看誰造成的 cache miss 最多。

它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者補丁分支（hotfix branch）。完成開發後，該分支就合併到主分支，然後被刪除。

3使用 perf record, 解讀 report

使用 top 和 stat 之後，您可能已經大致有數了。要進一步分析，便需要一些粒度更細的資訊。比如說您已經斷定標的程式計算量較大，也許是因為有些程式碼寫的不夠精簡。那麼面對長長的程式碼檔案，究竟哪幾行程式碼需要進一步修改呢？這便需要使用 perf record 記錄單個函式級別的統計資訊，並使用 perf report 來顯示統計結果。

您的調優應該將註意力集中到百分比高的熱點程式碼片段上，假如一段程式碼只佔用整個程式執行時間的 0.1%，即使您將其最佳化到僅剩一條機器指令，恐怕也只能將整體的程式效能提高 0.1%。俗話說，好鋼用在刀刃上，不必我多說了。

仍以 t1 為例。

perf record – e cpu-clock ./t1 
 perf report

結果如下圖所示：

不出所料，hot spot 是 longa( ) 函式。

但，程式碼是非常複雜難說的，t1 程式中的 foo1() 也是一個潛在的調優物件，為什麼要呼叫 100 次那個無聊的 longa() 函式呢？但我們在上圖中無法發現 foo1 和 foo2，更無法瞭解他們的區別了。

我曾發現自己寫的一個程式居然有近一半的時間花費在 string 類的幾個方法上，string 是 C++ 標準，我絕不可能寫出比 STL 更好的程式碼了。因此我只有找到自己程式中過多使用 string 的地方。因此我很需要按照呼叫關係進行顯示的統計資訊。

使用 perf 的 -g 選項便可以得到需要的資訊：

perf record – e cpu-clock – g ./t1 
 perf report

結果如下圖所示：

透過對 calling graph 的分析，能很方便地看到 91% 的時間都花費在 foo1() 函式中，因為它呼叫了 100 次 longa() 函式，因此假如 longa() 是個無法最佳化的函式，那麼程式員就應該考慮最佳化 foo1，減少對 longa() 的呼叫次數。

它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者補丁分支（hotfix branch）。完成開發後，該分支就合併到主分支，然後被刪除。

使用 PMU 的例子

例子 t1 和 t2 都較簡單。所謂魔高一尺，道才能高一丈。要想演示 perf 更加強大的能力，我也必須想出一個高明的影響效能的例子，我自己想不出，只好藉助於他人。下麵這個例子 t3 參考了文章“Branch and Loop Reorganization to Prevent Mispredicts”[6]

該例子考察程式對奔騰處理器分支預測的利用率，如前所述，分支預測能夠顯著提高處理器的效能，而分支預測失敗則顯著降低處理器的效能。首先給出一個存在 BTB 失效的例子：

清單 3. 存在 BTB 失效的例子程式

//test.c 
 #include  
 #include  

 void foo() 
 { 
  int i,j; 
  for(i=0; i< 10; i++) 
  j+=2; 
 } 
 int main(void) 
 { 
  int i; 
  for(i = 0; i< 100000000; i++) 
  foo(); 
  return 0; 
 }

用 gcc 編譯生成測試程式 t3:

gcc – o t3 – O0 test.c

用 perf stat 考察分支預測的使用情況：

[lm@ovispoly perf]$ ./perf stat ./t3 

 Performance counter stats for './t3': 
 6240.758394 task-clock-msecs # 0.995 CPUs 
 126 context-switches # 0.000 M/sec 
 12 CPU-migrations # 0.000 M/sec 
 80 page-faults # 0.000 M/sec 
 17683221 cycles # 2.834 M/sec (scaled from 99.78%) 
 10218147 instructions # 0.578 IPC (scaled from 99.83%) 
 2491317951 branches # 399.201 M/sec (scaled from 99.88%) 
 636140932 branch-misses # 25.534 % (scaled from 99.63%) 
 126383570 cache-references # 20.251 M/sec (scaled from 99.68%) 
 942937348 cache-misses # 151.093 M/sec (scaled from 99.58%) 
  6.271917679 seconds time elapsed

可以看到 branche-misses 的情況比較嚴重，25% 左右。我測試使用的機器的處理器為 Pentium4，其 BTB 的大小為 16。而 test.c 中的迴圈迭代為 20 次，BTB 上限溢位，所以處理器的分支預測將不準確。

對於上面這句話我將簡要說明一下，但關於 BTB 的細節，請閱讀參考文獻 [6]。

for 迴圈編譯成為 IA 彙編後如下：

清單 4. 迴圈的彙編

// C code 
 for ( i=0; i < 20; i++ ) 
 { … } 

 //Assembly code; 
 mov    esi, data 
 mov    ecx, 0 
 ForLoop: 
 cmp    ecx, 20 
 jge    
 EndForLoop 
…
 add    ecx, 1 
 jmp    ForLoop 
 EndForLoop:

可以看到，每次迴圈迭代中都有一個分支陳述句 jge，因此在執行過程中將有 20 次分支判斷。每次分支判斷都將寫入 BTB，但 BTB 是一個 ring buffer，16 個 slot 寫滿後便開始改寫。假如迭代次數正好為 16，或者小於 16，則完整的迴圈將全部寫入 BTB，比如迴圈迭代次數為 4 次，則 BTB 應該如下圖所示：

這個 buffer 完全精確地描述了整個迴圈迭代的分支判定情況，因此下次運行同一個迴圈時，處理器便可以做出完全正確的預測。但假如迭代次數為 20，則該 BTB 隨著時間推移而不能完全準確地描述該迴圈的分支預測執行情況，處理器將做出錯誤的判斷。

我們將測試程式進行少許的修改，將迭代次數從 20 減少到 10，為了讓邏輯不變，j++ 變成了 j+=2；

清單 5. 沒有 BTB 失效的程式碼

#include  
 #include  

 void foo() 
 { 
  int i,j; 
  for(i=0; i< 10; i++) 
  j+=2; 
 } 
 int main(void) 
 { 
  int i; 
  for(i = 0; i< 100000000; i++) 
  foo(); 
  return 0; 
 }

此時再次用 perf stat 取樣得到如下結果：

[lm@ovispoly perf]$ ./perf stat ./t3 
  Performance counter stats for './t3: 
 2784.004851 task-clock-msecs # 0.927 CPUs 
 90 context-switches # 0.000 M/sec 
 8 CPU-migrations # 0.000 M/sec 
 81 page-faults # 0.000 M/sec 
 33632545 cycles # 12.081 M/sec (scaled from 99.63%) 
 42996 instructions # 0.001 IPC (scaled from 99.71%) 
 1474321780 branches # 529.569 M/sec (scaled from 99.78%) 
 49733 branch-misses # 0.003 % (scaled from 99.35%) 
 7073107 cache-references # 2.541 M/sec (scaled from 99.42%) 
 47958540 cache-misses # 17.226 M/sec (scaled from 99.33%) 
  3.002673524 seconds time elapsed

Branch-misses 減少了。

本例只是為了演示 perf 對 PMU 的使用，本身並無意義，關於充分利用 processor 進行調優可以參考 Intel 公司出品的調優手冊，其他的處理器可能有不同的方法，還希望讀者明鑒。