Linux性能優化2.2 Linux性能工具：CPU

<b>2.2　linux性能工具：cpu</b>

<b></b>

現在開始讨論性能工具，使用這些工具能夠提取之前描述的那些資訊。

2.2.1　vmstat（虛拟記憶體統計）

vmstat是指虛拟記憶體統計，這個名稱表明它能告訴你系統的虛拟記憶體性能資訊。幸運的是，它實際上能完成的工作遠不止于此。vmstat是一個很有用的指令，它能擷取整個系統性能的粗略資訊，包括：

正在運作的程序個數。

cpu的使用情況。

cpu接收的中斷個數。

排程器執行的上下文切換次數。

它是用于擷取系統性能大緻資訊的極好工具。

2.2.1.1　cpu性能相關的選項

vmstat可以被如下指令行調用：

vmstat運作于兩種模式：采樣模式和平均模式。如果不指定參數，則vmstat統計運作于平均模式下，vmstat顯示從系統啟動以來所有統計資料的均值。但是，如果指定了延遲，那麼第一個采樣仍然是系統啟動以來的均值，但之後vmstat按延遲秒數采樣系統并顯示統計資料。表2-1解釋了vmstat的選項。

表2-1　vmstat指令行選項

選　　項 說　　明

-n 預設情況下，vmstat定期顯示每個性能統計資料的列标題。本選項禁止該特性，是以初始列标題之後，隻顯示性能資料。如果想要将vmstat導出為電子表格，使用這個選項是有好處的

-s 本選項一次性輸出vmstat收集的系統統計的詳細資訊。該資訊為系統啟動後的總資料

delay vmstat采樣的間隔時間

vmstat提供的各種統計輸出資訊，使你能跟蹤系統性能的不同方面。表2-2解釋了與cpu性能相關的輸出。下一章說明與記憶體性能相關的輸出。

表2-2　與cpu相關的vmstat輸出

列 說　　明

r 目前可運作的程序數。這些程序沒有等待i/o，而是已經準備好運作。理想狀态下，可運作程序數應與可用cpu的數量相等

b 等待i/o完成的被阻塞程序數

forks 建立新程序的次數

in 系統發生中斷的次數

cs 系統發生上下文切換的次數

us 使用者程序消耗的總cpu時間的百分比（包括“友好的”時間）

sy 系統代碼消耗的總cpu時間的百分比，其中包括消耗在system、irq和softirq狀态的時間

wa 等待i/o消耗的總cpu時間的百分比

id 系統空閑消耗的總cpu時間的百分比

vmstat提供了一個低開銷的良好系統性能視圖。由于所有的性能統計資料都以文本形式呈現，并列印到标準輸出，是以，捕捉測試中生成的資料，以及之後對其進行處理和繪圖就會很友善。由于vmstat的開銷如此之低，是以當你需要一目了然地監控系統健康狀況時，讓它在控制台上或視窗中持續運作，甚至是在負載非常重的伺服器上是很實用的。

2.2.1.2　用法示例

如清單2.2所示，如果vmstat運作時沒有使用指令行參數，顯示的将是自系統啟動後它記錄下的統計資訊的均值。根據“cpu使用率”列下面的us、sy、wa和id，本例顯示出系統從啟動開始，基本上處于空閑狀态。從啟動開始，cpu有5%的時間用于執行使用者應用程式代碼，1%的時間用于執行系統代碼，而其餘94%的時間處于空閑狀态。

清單2.2

盡管vmstat從系統啟動時開始統計有助于确定系統的負載情況，但是，vmstat最有用的是運作于采樣模式下，如清單2.3所示。在采樣模式下，vmstat間隔delay參數指定的秒數輸出系統統計資料，而采樣次數由count給出。清單2.3第一行的統計資料和之前一樣，是系統啟動以來的均值，但之後就是定期采樣。本例展示出系統的活動非常少。通過檢視b列下面的0，我們可以知道在運作時沒有阻塞程序。通過檢視r列，我們還可以看到在vmstat采樣資料時，正在運作的程序數量少于1。

清單2.3

vmstat是一種記錄系統在一定負載或測試條件下行為的好方法。可以用vmstat顯示系統的行為，同時利用linux的tee指令将結果輸出到檔案。（第8章較長的描述了tee指令。）如果你隻傳遞了參數delay，vmstat就會無限采樣。在測試開始前啟動vmstat，測試結束後終止vmstat。輸出檔案的形式可以是電子表格，并能夠用于檢視系統對負載和各種系統事件是如何反應的。清單2.4給出了按照這個方法得到的輸出。在這個例子中，我們可以檢視到系統發生的中斷和上下文切換。在in列和cs列能分别檢視到中斷和上下文切換的總數。

上下文切換的數量小于中斷的數量。排程器切換程序的次數少于定時器中斷觸發的次數。這很可能是因為系統基本上是空閑的，在定時器中斷觸發的大多數時候，排程器沒有任何工作要做，是以它也不需要從空閑程序切換出去。

（注意：生成如下輸出的vmstat版本有錯誤。它會導緻系統輸出的平均線顯示不正确的數值。該錯誤已經報告給了vmstat的維護者，希望能盡快修複。）

清單2.4

最新版本的vmstat甚至可以抽取各種系統統計資料更詳細的資訊，如清單2.5所示。

下一章讨論記憶體統計資料，但是，現在我們來檢視cpu的統計資訊。第一組資料，即“cpu ticks”，顯示的是自系統啟動的cpu時間，這裡的“tick”是一個時間機關。雖然精簡的vmstat輸出僅顯示四個cpu狀态—us、sy、id和wa，這裡則顯示了全部cpu ticks的分布情況。此外，我們還可以看到中斷和上下文切換的總數。一個新添加的内容是forks，它大體上表示的是從系統啟動開始，已經建立的新程序的數量。

清單2.5

vmstat提供了關于linux系統性能的衆多資訊。在調查系統問題時，它是核心工具之一。

2.2.2　top（2.0.x版本）

top是linux系統監控工具中的瑞士軍刀。它善于将相當多的系統整體性能資訊放在一個螢幕上。顯示内容還能以互動的方式進行改變，是以，在系統運作時，如果一個特定的問題不斷突顯，你可以修改top顯示的資訊。

預設情況下，top表現為一個将占用cpu最多的程序按降序排列的清單。這使得你能夠迅速找出是哪個程式獨占了cpu。top根據指定的延遲定期更新這個清單（其初始值為3秒）。

2.2.2.1　cpu性能相關的選項

top用如下指令行調用：

top實際上有兩種模式的選項：指令行選項和運作時選項。指令行選項決定top如何顯示其資訊。表2-3給出的指令行選項會影響top顯示的性能統計資訊的類型和頻率。

表2-3　top指令行選項

d delay 統計資料更新的時間間隔

n iterations 退出前的疊代次數。top更新統計資料的次數為iterations次

i 不顯示未使用任何cpu的程序

h 顯示應用程式所有的單個線程，而不僅僅給出每個應用程式的總和

c 對超線程或smp系統，顯示cpu統計資料總和，而不是每個cpu的資料

在你運作top時，為了調查特定問題，你可能想要對你的觀察略作調整。top輸出的可定制性很高。表2-4給出的選項可以在top運作期間修改顯示的統計資訊：

表2-4　top運作時統計資訊顯示選項

f或f 顯示一個配置界面，用于選擇在螢幕上顯示哪些程序統計資訊

o或o 顯示一個配置界面，用于修改顯示統計資訊的順序

表2-5給出的選項打開或關閉各種系統級資訊的顯示。關閉不需要的統計資訊有助于在螢幕上顯示更多程序。

表2-5　top運作時輸出切換選項

l 切換更新和顯示平均負載以及正常運作時間資訊

t 切換顯示每個cpu消耗時間的情況。它還切換顯示目前運作的程序數量。顯示應用程式全部的獨立線程，而不是顯示每個應用程式的總數

m 在螢幕上切換顯示系統記憶體使用資訊。預設情況下，最占用cpu的程序第一個顯示。不過，按照其他特征排序可能更有用

表2-6對top支援的不同排序模式進行了說明。按記憶體消耗量排序尤其有用，它能找出哪個程序消耗了最多的記憶體。

表2-6　top輸出排序/顯示選項

p 按cpu消耗量對任務排序。最高的cpu使用者第一個顯示

t 按到目前為止使用的cpu時間總量對任務排序。總量最高的第一個顯示

n 按任務的pid進行排序。pid最低的第一個顯示

a 按任務時長進行排序。最新的pid第一個顯示。通常與“按pid排序”相反

i 隐藏空閑和不消耗cpu的任務

top除了提供特定程序的資訊之外，還提供系統整體資訊。表2-7給出了這些統計資訊。

表2-7　top性能統計資訊

us 使用者應用程式消耗的cpu時間

sy 核心消耗的cpu時間

ni “友好的”程序消耗的cpu時間

id 空閑的cpu時間

wa 等待i/o的cpu時間

hi irq處理程式消耗的cpu時間

si softirq處理程式消耗的cpu時間

load average 1分鐘、5分鐘和15分鐘的平均負載

%cpu 特定程序消耗cpu時間的百分比

pri 程序優先級，值越大表示優先級越高。rt代表任務為實時優先級，該優先級高于标準範圍

ni 程序的nice值。nice值越高，系統執行該程序的必要性就越低。對于具有高nice值的程序，通常其優先級會非常低

wchan 若程序在等待i/o，該項顯示其等待的是哪個核心函數

stat 程序目前狀态。這裡，程序可以是睡眠狀态（s），運作狀态（r），僵屍狀态（要求終止但還未終止）（z），不可中斷的睡眠狀态（d），或者跟蹤狀态（t）

time 自程序開始執行起已消耗的總的cpu時間（使用者和系統）

command 程序正在執行的指令

lc 程序執行時最後使用的cpu編号

flags 該項切換是否更新和顯示平均負載與正常運作時間資訊

top提供了不同的正在運作程序的大量資訊，是找出資源消耗大戶的極好方法。

2.2.2.2　用法示例

清單2.6是運作top的一個例子。當它啟動後，将會周期性地更新螢幕直到退出。該例展示了top能生成的一些系統整體統計資訊。首先。我們能看到1分鐘、5分鐘和15分鐘的系統平均負載。可以看出，系統已經開始忙碌起來（因為doom-3.x86）。一個cpu在使用者代碼上花費了90%的時間。另一個則隻在使用者代碼上花費了約13%的時間。最後，我們看到73個程序處于睡眠狀态，隻有3個程序正在運作。

清單2.6

現在，在top運作時按下f鍵彈出配置界面，如清單2.7所示。當你按下代表鍵（a代表pid，b代表ppid，等等）時，top将切換這些統計資訊在螢幕上的顯示。選擇好需要的全部統計資訊後，按下enter鍵傳回top的初始界面，現在它顯示的是選出的統計資訊的目前值。在配置統計資訊時，所有目前選擇的字段将會以大寫形式顯示在current field order行，并在其名稱旁出現一個星号（*）。

清單2.7

為了展示top的可定制性，清單2.8給出了一個高度配置的輸出界面，其中隻顯示了與cpu使用率相關的top選項：

清單2.8

top提供了一個系統資源使用率的總覽，其重點資訊在于各種程序是如何消耗這些資源的。由于其輸出格式對使用者是友好的，而對工具是不友好的，是以最好是在與系統直接互動時使用。

2.2.3　top（3.x.x版本）

近來，最新版本中提供的top已經有了徹底的改變，其結果就是很多指令行和互動選項發生了變化。雖然基本思路是相似的，但對top進行了精簡，并添加了幾個不同的顯示模式。

同樣的，top呈現為一個降序清單，排在最前面的是最占用cpu的程序。

2.2.3.1　cpu性能相關的選項

用如下指令行調用top：

top實際有兩種模式的選項：指令行選項和運作時選項。指令行選項決定top如何顯示其資訊。表2-8給出的指令行選項會影響top顯示的性能統計資訊的類型和頻率。

表2-8　top指令行選項

-d delay 統計資訊更新的時間間隔

-n iterations 退出前疊代的次數。top更新統計資訊的次數為iterations次

-i 是否顯示空閑程序

-b 以批處理模式運作。通常，top隻顯示單屏資訊，超出該螢幕的程序不顯示。該選項顯示全部程序，如果你要将top的輸出儲存為檔案或将輸出流水給另一個指令進行處理，那麼該項是很有用的

運作top時，為了調查特定問題，你可能想要對你的觀察略作調整。和top 2.x版本一樣，其輸出的可定制性很高。表2-9給出的選項可以在top運作期間修改顯示的統計資訊。

表2-9　top運作時選項

a 程序資訊的“另一種”顯示方式，其内容為各種系統資源最大的消耗者

i 選擇top是否用系統中的cpu數量除以cpu使用率

例如，一個系統中有兩個cpu，如果一個程序占用了這兩個cpu，那麼這個選項将在top顯示cpu使用率為100%或200%之間切換

f 顯示配置界面，選擇在螢幕上顯示哪些統計資訊

o 顯示配置界面，修改統計資訊的顯示順序

表2-10給出的選項打開或關閉各種系統級資訊的顯示。關閉不需要的統計資訊有助于在螢幕上顯示更多程序。

表2-10　top運作時輸出切換選項

1（數字1） 切換cpu使用率是按獨立使用率顯示還是按總量顯示

1 切換是否更新和顯示平均負載和正常運作時間資訊

與top v2.x相同，top v3.x除了提供特定程序的資訊之外，還提供系統整體資訊。表2-11給出了這些統計資訊。

表2-11　top性能統計資訊

ni 修改過“友好”值的程序消耗的cpu時間

ni 程序的nice值。nice值越高，系統執行該程序的必要性就越低。具有高nice值的程序通常其優先級會非常低

s 程序目前的狀态。這裡，程序可以是睡眠狀态（s），運作狀态（r），僵屍狀态（要求終止但還未終止）（z），不可中斷的睡眠狀态（d），或者跟蹤狀态（t）

top提供了不同的正在運作程序的大量資訊，是找出資源消耗大戶的極好方法。top v.3版對top進行了精簡，并增加了一些對相同資料的不同視圖。

2.2.3.2　用法示例

清單2.9是運作top v3.0的一個例子。同樣的，它會周期性地更新螢幕直到退出。其統計資訊與top v2.x相同，但名稱略有改變。

清單2.9

現在，在top運作時按下f鍵調出配置界面，如清單2.10所示。當你按下代表鍵（a代表pid，b代表ppid等）時，top将切換這些統計資訊在螢幕上的顯示。選擇好需要的全部統計資訊後，按下enter鍵傳回top的初始界面，現在它顯示的是被選出的統計資訊的目前值。在配置統計資訊時，所有目前被選擇的字段将會以大寫形式顯示在current field order行，并在其名稱旁出現一個星号（*）。請注意，大多數統計資訊都是相同的，但名稱略有變化。

清單2.10

清單2.11展示了新的top輸出模式，許多不同的統計資訊進行了分類并顯示在同一螢幕上。

清單2.11

top v3.x為top提供了稍簡潔的界面。它簡化了top的某些方面，并提供了一個很好的“總結”資訊屏，顯示了系統中的許多資源消費者。

2.2.4　procinfo（從/proc檔案系統顯示資訊）

就像vmstat一樣，procinfo也為系統整體資訊特性提供總覽。盡管它提供的有些資訊與vmstat相同，但它還會給出cpu從每個裝置接收的中斷數量。其輸出格式的易讀性比vmstat稍微強一點，但卻會占用更多的螢幕空間。

2.2.4.1　cpu性能相關的選項

procinfo的調用指令行如下：

表2-12描述了不同的選項，用于修改procinfo顯示樣本的輸出和頻率。

表2-12　procinfo指令行選項

-f 全屏運作procinfo

-d 顯示樣本統計資訊的變化，而非總和

-d 顯示統計資訊的總和，而非變化率

-n sec 樣本之間停頓的秒數

-ffile 将procinfo的輸出發送到檔案

表2-13給出了procinfo收集的cpu統計資訊。

表2-13　procinfo　cpu 統計資訊

user cpu花費的總的使用者時間，形式為天、小時和分鐘

nice cpu花費的總的友好時間，形式為天、小時和分鐘

system cpu花費的總的系統時間，形式為天、小時和分鐘

idle cpu花費的總的空閑時間，形式為天、小時和分鐘

irq 0-n 顯示irq的編号，已經啟動的次數，以及哪個核心驅動程式應對其負責

與vmstat以及top一樣，procinfo是一個低開銷的指令，适合于讓其自行在控制台或螢幕視窗運作。它能夠很好地反映系統的健康和性能。

2.2.4.2　用法示例

調用procinfo時不帶任何指令選項将産生如清單2.12所示的輸出。無參數，則procinfo僅顯示一屏狀态資訊并退出。使用-n second選項讓procinfo周期性地更新，其作用會更大。這能使你檢視到系統性能的實時變化。

清單2.12

如同你在清單2.12中所見，procinfo為系統提供了不錯的總覽。從使用者、nice、系統和空閑時間，我們再次發現，系統不是很忙。一個值得注意的有趣現象是，procinfo表明系統空閑時間比其運作時間（用uptime表示）還要多。這是因為系統實際上有4個cpu，是以，對于一天的牆鐘時間而言，cpu時間已經過去了四天。平均負載證明系統近期相對沒有多少工作。在過去的時間裡，平均而言，系統準備運作的程序還不到一個；平均負載為0.47意味着單個程序準備運作的時間隻有47%。對于有四個cpu的系統來說，将會浪費大量的cpu能力。

procinfo還給我們提供了很好的視圖來說明系統中的哪個裝置導緻了中斷。可以看到顯示卡（nvidia）、硬碟控制器（ide0）、以太網裝置（eth0）以及聲霸卡（es1371）的中斷數量相對較高。這些情況一般出現在台式工作站上。

procinfo的優勢是将許多系統級性能統計資訊放在一個螢幕裡，讓你能了解系統整體執行情況。它缺乏網絡和磁盤性能的詳細資訊，但能為cpu和記憶體性能的統計資訊提供良好的細節。一個可能很重要的限制是，cpu處于iowait、irq或softirq模式時procinfo不會進行報告。

2.2.5　gnome-system-monitor

gnome-system-monitor在很多方面都可以說是top的圖形化。它使你能以圖形方式監控各個程序，并在顯示圖表的基礎上觀察系統負載。

2.2.5.1　cpu性能相關的選項

gnome-system-monitor可以從gnome菜單調用。（red hat 9及其以上版本中，選擇菜單system tools→system monitor。）不過，它也可以用如下指令調用：

gnome-system-monitor沒有相關指令行選項來影響cpu性能測量。但是，有些顯示的統計資訊可以通過選擇gnome-system-monitor的edit→preferences菜單項進行修改。

2.2.5.2　用法示例

當你啟動gnome-system-monitor時，它會建立與圖2-1相似的視窗。該視窗顯示了特定程序使用的cpu和記憶體總量資訊。它還顯示了程序之間父/子關系的資訊。

圖2-2顯示了系統負載和記憶體使用率的圖形視圖。從這一點可以真正區分gnome-system-monitor與top。你可以很容易地檢視系統目前狀态，以及與之前狀态的對比。

gnome-system-monitor提供的資料圖形視圖能夠更容易更迅速地确定系統狀态及其行為随時間的變化。它還能更輕松地浏覽系統級程序資訊。

2.2.6　mpstat（多處理器統計）

mpstat是一個相當簡單的指令，向你展示随着時間變化的cpu行為。mpstat最大的優點是在統計資訊的旁邊顯示時間，由此，你可以找出cpu使用率與時間的關系。

如果你有多個cpu或超線程cpu，mpstat還能夠把cpu使用率按處理器進行區分，是以你可以發現與其他處理器相比，是否某個處理器做了更多的工作。你可以選擇想要監控的單個處理器，也可以要求mpstat對所有的處理器都進行監控。

2.2.6.1　cpu性能相關的選項

mpstat可以用如下指令行調用：

和之前一樣，delay指定了采樣間隔，count指定了采樣次數。表2-14解釋了mpstat指令行選項的含義。

表2-14　mpstat指令行選項

-p {cpu | all} 告訴mpstat監控哪個cpu，cpu取值範圍為0~（cpu總數-1）

delay 指明mpstat在采樣之間應等待的時長

mpstat提供與其他cpu性能工具相似的資訊，但是，它允許将資訊按照特定系統中的單個處理器進行分類。表2-15給出了mpstat支援的選項。

表2-15　mpstat cpu統計資訊

user 前一個采樣中cpu消耗在使用者時間上的百分比

nice 前一個采樣中cpu執行低優先級（或nice）程序消耗時間的百分比

system 前一個采樣中cpu消耗在系統時間上的百分比

iowait 前一個采樣中cpu等待i/o消耗時間的百分比

irq 前一個采樣中cpu進行中斷消耗時間的百分比

softirq 前一個采樣中，中斷處理後，核心完成所需工作消耗的cpu時間百分比

idle 前一個采樣中cpu空閑時間百分比

mpstat是一種很好的工具，可以分類提供每個處理器的執行情況。由于mpstat給出了每個cpu的明細，是以你可以識别是否有哪個處理器正逐漸出現超負載情況。

2.2.6.2　用法示例

首先，我們要求mpstat顯示處理器編号為0的cpu的統計資訊，如清單2.13所示。

清單2.13

清單2.14顯示了對典型無負載超線程cpu使用相同指令産生的結果。你可以看到所有顯示出來的cpu統計資料。輸出中有個有趣的現象，即其中一個cpu似乎處理了所有的中斷。如果系統有很重的i/o負載，而全部中斷又都是由一個處理器處理，那麼這可能就是瓶頸，因為一個cpu超負荷，而其他cpu則在等待。如果一個cpu忙于處理所有的中斷以至于沒有空閑時間，而與此同時，其他處理器則處于空閑狀态，那麼你可以用mpstat發現這種情況。

清單2.14

mpstat可以用來确定cpu是否得到充分利用，以及使用情況是否相對均衡。通過觀察每個cpu處理的中斷數，有可能發現其中的不均衡。如何控制中斷路由的詳細資訊參見documentation/irq-affinity.txt下的核心源碼。

2.2.7　sar（系統活動報告）

sar用另一種方法來收集系統資料。sar能有效地将收集到的系統性能資料記錄到二進制檔案，之後，可以重播這些檔案。sar是一種低開銷的、記錄系統執行情況資訊的方法。

sar指令可以用于記錄性能資訊，回放之前的記錄資訊，以及顯示目前系統的實時資訊。sar指令的輸出可以進行格式化，使之易于導入資料庫，或是輸送給其他linux指令進行處理。

2.2.7.1　cpu性能相關的選項

sar可以使用如下指令行調用：

盡管sar的報告涉及linux多個不同領域，其統計資料有兩種不同的形式。一組統計資料是采樣時的瞬時值。另一組則是自上一次采樣後的變化值。表2-16解釋了sar的指令行選項。

表2-16　sar指令行選項

-c 報告每秒建立的程序數量

-i {irq | sum | all | xall } 報告系統已發生中斷的速率

-p { cpu | all} 該項确定從哪個cpu收集統計資訊。如果不指定，則報告系統整體情況

-q 報告機器的運作隊列長度和平均負載

-u 報告系統的cpu使用情況（該項為預設輸出）

-w 報告系統中已發生的上下文切換次數

-o filename 指定儲存性能統計資訊的二進制輸出檔案名

-f filename 指定性能統計資訊的檔案名

delay 需等待的采樣間隔時間

count 記錄的樣本總數

sar提供的系統級cpu性能統計資料集與我們在程序工具中看到的類似（名字不同）。如表2-17所示。

表2-17　sar cpu統計資訊

runq-sz 采樣時，運作隊列的長度

plist-sz 采樣時的程序（運作，睡眠或等待i/o）數

ldavg-1 前1分鐘的平均負載

ldavg-5 前5分鐘的平均負載

ladavg-15 前15分鐘的平均負載

proc/s 每秒建立程序數（該項等同于vmstat中的forks項）

cswch 每秒上下文切換次數

intr/s 每秒觸發的中斷次數

sar最顯著的優勢之一是，它使你能把不同類型時間戳系統資料儲存到日志檔案，以便日後檢索和審查。當試圖找出特定機器在特定時間出現故障的原因時，這個特性被證明是非常便利的。

2.2.7.2　用法示例

清單2.15顯示的第一個指令要求每秒有三個cpu采樣，其結果儲存到二進制檔案/tmp/apache_test。該指令沒有任何可視化輸出，完成即傳回。

清單2.15

資訊儲存到/tmp/apache_test檔案後，我們就能以各種格式顯示它。預設格式為人類可讀，如清單2.16所示。該清單顯示與其他系統監控指令類似的資訊，我們可以看出處理器在特定時間是如何消耗其時間的。

清單2.16

不過，sar還可以将統計資料輸出為一種能輕松導入關系資料庫的格式，如清單2.17所示。這有助于儲存大量的性能資料。一旦将其導入到關系資料庫，就可以用所有的關系資料庫工具對這些性能資料進行分析。

清單2.17

最後，sar還有一種易于被标準linux工具，如awk，perl，python或grep，解析的統計資料輸出格式。如清單2.18所示，這種輸出可以被送入腳本，該腳本會引發有趣的事件，甚至有可能分析出資料的不同趨勢。

清單2.18

除了将資訊記錄到檔案之外，sar還可以用于實時系統觀察。在清單2.19所示的例子中，cpu狀态被采樣了三次，采樣間隔時間為一秒。

清單2.19

預設顯示的目的是展示cpu的資訊，但是也可以顯示其他資訊。比如，sar可以顯示每秒的上下文切換次數，以及交換的記憶體頁面數。在清單2.20中，sar采樣了兩次資訊，間隔時間為一秒。這次，我們要求sar顯示每秒上下文切換的數量以及建立的程序數。我們還要求sar給出平均負載的資訊。可以看出來，本例中的機器有163個程序在記憶體中，但都沒有運作。過去的一分鐘平均有1.12個程序等待運作。

清單2.20

如你所見，sar是一個強大的工具，能夠記錄多種不同的性能統計資訊。它提供了linux友好界面，使你可以輕松地提取和分析性能資料。

2.2.8　oprofile

oprofile是性能工具包，它利用幾乎所有現代處理器都有的性能計數器來跟蹤系統整體以及單個程序中cpu時間的消耗情況。除了測量cpu周期消耗在哪裡之外，oprofile還可以測量關于cpu執行的非常底層的資訊。根據由底層處理器支援的事件，它可以測量的内容包括：cache缺失、分支預測錯誤和記憶體引用，以及浮點操作。

oprofile不會記錄發生的每個事件，相反，它與處理器性能硬體一起工作，每count個事件采樣一次，這裡的count是一個數值，由使用者在啟動oprofile時指定。count的值越低，結果的準确度越高，而oprofile的開銷越大。若count保持在一個合理的數值，那麼，oprofile不僅運作開銷非常低，并且還能以令人驚訝的準确性描述系統性能。

采樣是非常強大的，但使用時要小心一些不明顯的陷阱。首先，采樣可能會顯示你有90%的時間花在了一個特定的例程上，但它不會顯示原因。一個特定例程消耗了大量周期有兩種可能的原因。其一，該例程可能是瓶頸，其執行需要很多時間。但是，也可能例程的執行時間是合理的，而其被調用的次數非常高。通常有兩種途徑可以發現究竟是哪一種情況：通過檢視采樣找出特别熱門的行，或是通過編寫代碼來計算例程被調用次數。

采樣的第二個問題是你永遠無法十分确定一個函數是從哪裡被調用的。即使你已經搞明白它被調用了很多次，并且已經跟蹤到了所有調用它的函數，但也不一定清楚其中哪個函數完成了絕大多數的調用。

2.2.8.1　cpu性能相關的選項

oprofile實際上是一組協同工作的元件，用于收集cpu性能統計資訊。oprofile主要有三個部分：

oprofile核心子產品控制處理器并允許和禁止采樣。

oprofile背景子產品收集采樣，并将它們儲存到磁盤。

oprofile報告工具擷取收集的采樣，并向使用者展示它們與在系統上運作的應用程式的關系。

oprofile工具包将驅動器和背景操作隐藏在opcontrol指令中。opcontrol指令用于選擇處理器采樣的事件并啟動采樣。

進行背景控制時，你可以使用如下指令行調用opcontrol：

此選項的控制（性能分析背景程序）使你能開始和停止采樣，并将樣本從守護程序的記憶體導入磁盤。采樣時，oprofile背景子產品将大量的采樣儲存在内部緩沖區。但是，它隻能分析那些已經寫入（或導入）磁盤的樣本。寫磁盤的開銷可能會很大，是以，oprofile隻會定期執行這個操作。其結果就是，運作測試并用oprofile分析後，可能不會馬上得到結果，你需要等待，直到背景将緩沖區寫入磁盤。當你想要立即開始分析時，這點是很讓人撓頭的，是以，opcontrol指令能讓你禁止将采樣從oprofile背景的内部緩沖區導入到磁盤。這将使你能在測試結束後，立刻開始性能調查。

表2-18介紹了opcontrol程式的選項，它們使你能控制背景操作。

表2-18　opcontrol背景控制

-s / - - start 若目前處理器未使用預設事件，則開始分析

-d / - - dump 将核心采樣緩沖區目前采樣資訊導入磁盤

- - stop 停止分析

預設情況下，oprofile按給定頻率選擇一個事件，這個頻率對于你在運作的處理器和核心來說是合理的。但是，比起預設事件來，還有更多的事件可以監控。當你列出并選擇了一個事件後，opcontrol将用如下指令行調用：

事件說明使你可以選擇采樣哪個事件，該事件的采樣頻率，以及采樣發生在核心空間、使用者空間或同時在這兩個空間。表2-19介紹了opcontrol的指令行選項，它們使你能選擇不同的事件進行采樣。

表2-19　opcontrol事件處理

-l/ - - list-events 列出處理器可以采樣的不同僚件

-event=:name:count:

unitmask:kernel:user: 用于指定被采樣的事件。事件名必須為處理器支援的事件之一。可用事件可以從--list-events選項擷取。參數count定義事件每發生count次，處理器将采樣一次。unitmask修改将要被采樣的事件。比如，如果你采樣“從記憶體讀”，那麼單元屏蔽（unit mask）可以讓你隻選擇那些cache未命中的讀操作。參數kernel指明，當處理器運作于核心空間時oprofile是否采樣。參數user指明，當處理器運作于使用者空間時oprofile是否采樣

- - vmlinux=kernel 說明oprofile對不同的核心函數采樣将使用哪個非壓縮核心映像

收集并儲存樣本後，oprofile提供另一種不同的工具opreport，該工具使你能檢視已收集的樣本。opreport的調用指令行如下：

通常，opreport顯示所有系統收集到的樣本，以及哪些可執行程式引起的這些樣本（包括核心）。樣本數最多的可執行線程排在第一位，其後為所有有樣本的可執行線程。在一個典型系統中，排在清單前面的是擁有大多數樣本的少數可執行線程，而大量的可執行線程隻貢獻了數量很少的樣本。針對這種情況，opreport允許你設定門檻值，隻有樣本數量百分比達到或超過門檻值的可執行線程才能顯示。同時，opreport還可以将可執行線程的顯示順序倒過來，那些擁有最多樣本數的将最後顯示。這種方式下，最重要的資料顯示在最後，那麼它就不會滾過螢幕。

表2-20說明了opreport的指令行選項，它們使你能定制采樣輸出的格式。

表2-20　opreport報告格式

- - reverse-sort / - r 颠倒顯示順序。通常，引起最多事件的映像最先顯示

- - threshold / - t

[percentage] 使opreport隻顯示樣本比例達到percentage或更高的映像。該項适用條件為：很多映像的樣本數非常小，而你隻對樣本數量最多的感興趣

再次說明，oprofile是一個複雜的工具，給出的這些選項僅僅是oprofile的基礎功能。在後續章節中，你将學習到oprofile更多的功能。

2.2.8.2　用法示例

oprofile是非常強大的工具，但它的安裝有點困難。附錄b指導讀者如何在幾個主要的linux發行版上安裝和運作oprofile。

使用oprofile首先要按照分析對其進行設定。第一條指令如清單2.21所示，用opcontrol指令告訴oprofile工具包一個非壓縮的核心映像在什麼位置。oprofile需要知道這個檔案的位置，以便它将樣本配置設定給核心中的确切函數。

清單2.21

設定了目前核心的路徑後，我們可以開始分析。清單2.22中的指令告訴oprofile用預設事件開始采樣。這個事件根據處理器而變化，對目前處理器而言，這個事件是cpu_clk_unhalted。隻要處理器沒有停止，該事件将會采樣全部cpu周期。233869是指每233 869個事件會采樣處理器正在執行的指令。

清單2.22

現在已經開始采樣後，我們想要分析采樣結果。在清單2.23中，我們用報告工具來找出系統中發生了什麼。opreport報告了目前為止分析的内容。

清單2.23

盡管分析已經進行了一小段時間，但當opreport表明它無法找到樣本時，我們就會停止。發生這種情況的原因是：opreport指令在磁盤上查找樣本，而oprofile背景程式則在記憶體中存儲樣本并定期将其轉存到磁盤。當我們向opreport請求樣本清單時，它無法在磁盤上找到，是以就會報告沒有發現任何樣本。為了緩解這一問題，我們可以通過在opcontrol中增加dump選項來強制背景程式立刻轉存樣本，如清單2.24所示，這條指令使我們能檢視已收集的樣本。

清單2.24

opcontrol

将樣本轉存到磁盤後，我們再次嘗試要求oprofile給出報告，如清單2.25所示。這一次，我們得到了結果。報告中包含了收集樣本來源處理器的資訊，以及其監控事件的類型資訊。然後，報告按降序排列事件發生的數量，并列出它們發生在哪個可執行檔案中。我們可以看到，linux核心占據了全部時鐘的50%，emacs為14%，libc為12%。可以深入挖掘可執行檔案确定哪個函數占據了所有的時間，我們将在第4章讨論這個問題。

清單2.25

當我們啟動oprofile時，我們隻使用了opcontrol為我們選擇的預設事件。每個處理器都有一個非常豐富的可以被監控的事件集。在清單2.26中，我們要求opcontrol列出特定cpu可以獲得的全部事件。這個清單相當長，但在其中我們可以看到除了cpu_clk_unhalted之外，還可以監控data_mem_refs和dcu_lines_in。這些是記憶體子系統導緻的存儲事件，我們将在後續章節中讨論它們。

清單2.26

需要指明被監控事件的指令看上去有點麻煩，幸運的是，我們還可以利用oprofile的圖形化指令oprof_start以圖形方式啟動和停止采樣。這使得我們能以圖形方式選擇想要的事件，而沒有必要搞清楚用準确的方式在指令行中明确說明想要監控的事件。

在圖2-3所示的op_control例子中，我們告訴oprofile想要同時監控data_mem_refs和l2_ld事件。data_mem_refs事件可以告訴我們哪些應用程式使用了大量的記憶體子系統，哪些使用了l2 cache。具體到這個處理器，其硬體隻有兩個計數器可用于采樣，是以能同時使用的也隻有兩個事件。

用oprofile的圖形界面收集樣本後，我們現在可以分析這些資料了。如清單2.27所示，我們要求opreport顯示對其收集樣本的分析，所用形式與監控周期時的類似。在本例中，我們可以發現libmad庫占用了整個系統中資料記憶體通路的31%，成為記憶體子系統使用量最大的使用者。

圖　2-3

清單2.27

opreport提供的輸出展示了包含任何被采樣事件的所有系統庫和可執行程式。請注意并非所有的事件都被記錄下來，這是因為我們是在采樣，實際上隻會記錄事件的子集。通常這不是問題，因為如果一個特定的庫或可執行程式是性能問題，那麼它很可能會導緻高成本事件發生許多次。如果采樣是随機的，這些高成本使事件最終也會被采樣代碼所捕獲