容器中的診斷與分析2——live diagnosis——perf Linux下的內核測試工具——perf使用簡介 系統級性能分析工具 — Perf linux perf - 性能測試和優化工具 goo

 

Linux下的內核測試工具——perf使用簡介

系統級性能分析工具 — Perf

linux perf - 性能測試和優化工具：示例&應用

 

 從2.6.31內核開始，linux內核自帶了一個性能分析工具perf，可以進行函數級與指令級的熱點查找。

 

 介紹：

Perf是內置於Linux內核源碼樹中的性能剖析(profiling)工具。是Linux kernel自帶的系統性能優化工具

它基於事件採樣原理，以性能事件爲基礎，支持針對處理器相關性能指標與操做系統相關性能指標的性能剖析。

經常使用於性能瓶頸的查找與熱點代碼的定位。

 

優點：

與Linux Kernel的緊密結合，它能夠最早應用到加入Kernel的new feature。而像OProfile, GProf等一般會「慢一拍」。

pef能夠用於查看熱點函數，查看cashe miss的比率，從而幫助開發者來優化程序性能。

 

運行原理：

• 性能調優工具如 perf，Oprofile 等的基本原理都是對被監測對象進行採樣。是功能級和指令級熱外表
  • 在CPU的PMU registers中Get/Set performance counters來得到諸如instructions executed, cache-missed suffered, branches mispredicted等信息。
  • Linux kernel對這些registers進行了一系列抽象，因此你能夠按進程，按CPU或者按counter group等不一樣類別來查看Sample信息。
• 最簡單的情形是根據 tick 中斷進行採樣，即在 tick 中斷內觸發採樣點，在採樣點裏判斷程序當時的上下文。
  • 假如一個程序 90% 的時間都花費在函數 foo() 上，那麼 90% 的採樣點都應該落在函數 foo() 的上下文中。
  • 運氣不可捉摸，但我想只要採樣頻率足夠高，採樣時間足夠長，那麼以上推論就比較可靠。
  • 所以，經過 tick 觸發採樣，咱們即可以瞭解程序中哪些地方最耗時間，從而重點分析。
• 稍微擴展一下思路，就能夠發現改變採樣的觸發條件使得咱們能夠得到不一樣的統計數據：
  • 以時間點 ( 如 tick) 做爲事件觸發採樣即可以獲知程序運行時間的分佈。
  • 以 cache miss 事件觸發採樣即可以知道 cache miss 的分佈，即 cache 失效常常發生在哪些程序代碼中。如此等等。
  • 使用perf list（在root權限下運行），能夠列出全部的採樣事件。事件分爲如下三種：
    • Hardware Event 是由 PMU 硬件產生的事件，好比 cache 命中，當您須要瞭解程序對硬件特性的使用狀況時，便須要對這些事件進行採樣
    • Software Event 是內核軟件產生的事件，好比進程切換，tick 數等 ;
    • Tracepoint event 是內核中的靜態 tracepoint 所觸發的事件，這些 tracepoint 用來判斷程序運行期間內核的行爲細節，好比 slab 分配器的分配次數等。
    • 上述每個事件均可以用於採樣，並生成一項統計數據，時至今日，尚沒有文檔對每個 event 的含義進行詳細解釋。

 

 

CPU週期(cpu-cycles)：

是默認的性能事件，

是指CPU所能識別的最小時間單元，一般爲億分之幾秒，

是CPU執行最簡單的指令時所須要的時間，例如讀取寄存器中的內容，也叫作clock tick。

 

 

Perf是一個包含22種子工具的工具集，如下是最經常使用的5種：

• perf-list：
  • 用來查看perf所支持的性能事件，有軟件的也有硬件的。查看全部可用的counters
  • perf list [hw | sw | cache | tracepoint | event_glob]
    • hw：Hardware event，9個
    • sw：Software event，9個
    • cache：Hardware cache event，26個
    • tracepoint：Tracepoint event，775個

  • sw其實是內核的計數器，與硬件無關。

  • hw和cache是CPU架構相關的，依賴於具體硬件。

  • tracepoint是基於內核的ftrace，主線2.6.3x以上的內核版本才支持。

    • 何時須要使用 tracepoint 來採樣呢？
      • 對內核的運行時行爲的關心
        • 有些內核開發人員須要專一於特定的子系統，好比內存管理模塊。這便須要統計相關內核函數的運行狀況。另外，內核行爲對應用程序性能的影響也是不容忽視的：
        • 例如,報告詳細說明了在 ls 運行期間發生了多少次系統調用 ( 上例中有 101 次 )，多數系統調用都發生在哪些地方 (97% 都發生在 ld-2.12.so 中 )。

• perf-stat：概覽程序的運行狀況
  • 分析指定程序的性能概況。面對一個問題程序，最好採用自頂向下的策略。先總體看看該程序運行時各類統計事件的大概，再針對某些方向深刻細節。而不要一會兒扎進瑣碎細節，會一葉障目的
    • 有些程序慢是由於計算量太大，其多數時間都應該在使用CPU進行計算，這叫作CPUbound型；有些程序慢是由於過多的IO，這種時候其CPU利用率應該不高，這叫作IObound型；對於CPUbound程序的調優和IObound的調優是不一樣的。
    • Perfstat應該是您最早使用的一個工具。它經過歸納精簡的方式提供被調試程序運行的總體狀況和彙總數據。
    • 進行調優應該要找到熱點 ( 即最耗時的代碼片斷 )，再看看是否可以提升熱點代碼的效率。
  • perf stat [-e <EVENT> | --event=EVENT] [-a] - <command> [<options>]
  • task-clock：任務真正佔用的處理器時間，單位爲ms。CPUs utilized = task-clock / time elapsed，CPU的佔用率。
    • Task-clock-msecs：CPU 利用率，該值高，說明程序的多數時間花費在 CPU 計算上而非 IO。
  • context-switches：上下文的切換次數。
  • Cache-misses：程序運行過程當中整體的 cache 利用狀況，若是該值太高，說明程序的 cache 利用很差

  • CPU-migrations：處理器遷移次數。Linux爲了維持多個處理器的負載均衡，在特定條件下會將某個任務從一個CPU遷移到另外一個CPU。

  • page-faults：缺頁異常的次數。當應用程序請求的頁面還沒有創建、請求的頁面不在內存中，或者請求的頁面雖然在內存中，但物理地址和虛擬地址的映射關係還沒有創建時，都會觸發一次缺頁異常。另外TLB不命中，頁面訪問權限不匹配等狀況也會觸發缺頁異常。

  • cycles：消耗的處理器週期數。若是把被ls使用的cpu cycles當作是一個處理器的，那麼它的主頻爲2.486GHz。
    • 能夠用cycles / task-clock算出。
  • instructions：執行了多少條指令。IPC爲平均每一個cpu cycle執行了多少條指令。
  • branches：遇到的分支指令數。branch-misses是預測錯誤的分支指令數。
  • IPC：是 Instructions/Cycles 的比值，該值越大越好，說明程序充分利用了處理器的特性。
  • Cache-references: cache 命中的次數
  • Cache-misses: cache 失效的次數。
• perf-top：
  • 對於一個指定的性能事件(默認是CPU週期)，顯示消耗最多的函數或指令
  • perf top [-e <EVENT> | --event=EVENT] [<options>]

  • 要用於實時分析各個函數在某個性能事件上的熱度，可以快速的定位熱點函數，包括應用程序函數、模塊函數與內核函數，甚至可以定位到熱點指令。

  • 第一列：符號引起的性能事件的比例，默認指佔用的cpu週期比例。

  • 第二列：符號所在的DSO(Dynamic Shared Object)，能夠是應用程序、內核、動態連接庫、模塊。

  • 第三列：DSO的類型。[.]表示此符號屬於用戶態的ELF文件，包括可執行文件與動態連接庫)。[k]表述此符號屬於內核或模塊。

  • 第四列：符號名。有些符號不能解析爲函數名，只能用地址表示。

• perf-record：精確制導——定位程序瓶頸
  • 收集採樣信息，並將其記錄在數據文件中。
    • 隨後能夠經過其它工具(perf-report)對數據文件進行分析，結果相似於perf-top的。
  • 查找時間上的熱點函數
  • 3個問題
    • perf未能定位本地符號表對應的symbol和地址的對應關係：0x000003d4對應的什麼函數？
    • 採樣頻率不夠高，失去了一些函數的信息：顯然一些內核函數沒有顯示在上面的結果中，由於採樣頻率若是不夠高，那麼勢必會有一些函數中的採樣點沒有/
      • 用perf record -F count 來指定採樣頻率
    • 如何克服採樣的隨機性帶來的問題：爲了在測量更加逼近正確值，咱們採用屢次重複取平均值的方法來逼近真實值。（這裏能夠用-r來指定重複次數）
• perf-report：精確制導——定位程序瓶頸
  • 讀取perf ：record建立的數據文件，並給出熱點分析結果。
• perf-lock
  • 內核鎖的性能分析。
  • perf lock {record | report | script | info}

  • Name：內核鎖的名字。

  • aquired：該鎖被直接得到的次數，由於沒有其它內核路徑佔用該鎖，此時不用等待。

  • contended：該鎖等待後得到的次數，此時被其它內核路徑佔用，須要等待。

  • total wait：爲了得到該鎖，總共的等待時間。

  • max wait：爲了得到該鎖，最大的等待時間。

  • min wait：爲了得到該鎖，最小的等待時間。
• perm-kmem
  • slab分配器的性能分析。
  • perf kmem {record | stat} [<options>]

  • Callsite：內核代碼中調用kmalloc和kfree的地方。

  • Total_alloc/Per：總共分配的內存大小，平均每次分配的內存大小。

  • Total_req/Per：總共請求的內存大小，平均每次請求的內存大小。

  • Hit：調用的次數。

  • Ping-pong：kmalloc和kfree不被同一個CPU執行時的次數，這會致使cache效率下降。

  • Frag：碎片所佔的百分比，碎片 = 分配的內存 - 請求的內存，這部分是浪費的。

  • 有使用--alloc選項，還會看到Alloc Ptr，即所分配內存的地址
• probe-sched
  • 調度模塊分析。　
  • perf sched {record | latency | map | replay | script}

  • TASK：進程名和pid。

  • Runtime：實際的運行時間。

  • Switches：進程切換的次數。

  • Average delay：平均的調度延遲。

  • Maximum delay：最大的調度延遲。

  • Maximum delay at：最大調度延遲發生的時刻。
• perf-probe
  • 自定義探測點。

• 還有一些適用於較特殊場景的工具， 好比內核鎖、slab分配器、調度器，也支持自定義探測點。

 

[1]. Linux的系統級性能剖析工具系列，by 承剛

[2]. http://www.ibm.com/developerworks/cn/linux/l-cn-perf1/

[3]. http://www.ibm.com/developerworks/cn/linux/l-cn-perf2/

[4]. https://perf.wiki.kernel.org/index.php/Tutorial

 

 

 

 

 

 

 

 

 

 

 

google perftools分析程序性能

介紹

經過採樣的方式，給程序中cpu的使用狀況進行「畫像」

• 經過它所輸出的結果，咱們能夠對程序中各個函數（獲得函數之間的調用關係）耗時狀況一目瞭然
• 對程序作性能優化的時候，這個是很重要的，先把最耗時的若干個操做優化好，程序的總體性能提高應該十分明顯，這也是作性能優化的一個最爲基本的原則—先優化最耗時的

 

下載 gperftools：https://code.google.com/p/gperftools/downloads/detail?name=gperftools-2.0.tar.gz

 

搭配組件：

安裝圖形化分析工具kcachegrind：

• 來分析產生的profiling文件，linux環境下使用。
• 採用kcachegrind查看函數之間依賴，並分析程序性能

查看profile結果：pprof工具

• 是一個perl的腳本，經過這個工具，能夠將google-perftool的輸出結果分析得更爲直觀，輸出爲圖片、pdf等格式。
• 在使用pprof以前須要先安裝運行per15；若是要進行圖標輸出則須要安裝dot；若是須要--gv模式的輸出則須要安裝gv

 

sw其實是內核的計數器，與硬件無關。