命令總結：
1. top/vmstat 發現 wa%過高,vmstat b >1；
參考文章：
1. 關於Linux系統指令 top 之 %wa 占用高，用`iostat`探個究竟
最近測試一項目，性能非常不理想。老版本邏輯和功能都簡單時，性能是相當的好！接口點擊率是萬級的。誰知修改后上不了百。
架設Jboss服務器，業務邏輯用Java處理，核心模塊使用C++處理，使用JNI銜接。
本應用對CPU和硬盤第三非常敏感，因為有壓縮解壓和大量數據交互。起初作壓力測試時，發現服務器各資源使用都有剩余，而點擊率曲線波動卻非常大，簡單看似乎是應用程序有問題。
使用top查看Cpu各核的使用情況，發現一個非常詭異的現象：
1. 經常只有部分核是滿載的，另外一部分基本空閑；
2. 在CPU滿載時，%wa 的波動比較大，有時會占到較大比例。
所以，監控整個CPU時會發現CPU使用率不高，實際上任務總是分派到某個核上且導致對應核滿載。無法有效使用CPU，其它資源自然也難以有效調度。
廢話不多說，%wa指CPU等待磁盤寫入完成的時間。莫非是磁盤忙，怎樣證明是磁盤在忙？
首先看下%wa的解釋：Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.
起初用`lsof | less`查看文件的讀寫情況，發現/tmp目錄下有大量文件讀寫。經查證，是Jboss處理上傳文件會默認寫入到/tmp文件夾，然后再執行了一次拷貝到程序讀取的目錄。修改Jboss配置直接寫入到程序讀寫目錄，性能沒有本質上的改變。
關於CPU使用波動大，我們也在程序內部加了很多計時器，發現某些模塊在處理並發時會有響應時間很長的情況，這點證實了為什么點擊率波動很大。
但此模塊進行單進程串行測試時，每秒完成事務數是相當可觀的。一個進程每秒完成的事務數都比當前測試點擊率要高很多！使用多進程來測試此模塊時，發現“進程數=核數”時效果最佳。於是在Java層控制同時進入此模塊的數量，畢竟Java是調用JNI來使用此模塊，使用全局鎖來控制並發，最終結果沒有想象的那么理想，但明顯可以看出：通過控制並發數，能有效提高CPU的使用率，點擊率也上升了一些。
另外一個問題就是，CPU會出現一會滿載，一會空閑的情況，導致點擊率曲線仍然波動大的問題。商討后決定在C++代碼中加入“釋放CPU控制權”的邏輯，這樣就在代碼層來作了一個負載均衡。點擊率波動的問題得到了好轉，但點擊率仍然不理想，預期瓶頸是網絡而實際變成了CPU。
優化了壓縮解決的處理后，性能沒有明顯提升。這時我才想起%wa，我還沒有進一步證明是磁盤的閑忙程度。使用了一些監控工具，諸如：vmstat、sar、dstat、sysstat沒有發現對磁盤作非常詳細的監控。最后試了下iostat，搞定！
iostat的編譯非常簡單，就一個c文件，MakeFile里作者寫了一句話“Cann't be simpler”。直接make install就在目錄下生成了iostat的可執行文件，看一下幫助，執行 `iostat -cdDx 10` 。其中有一列“%b”描述了磁盤的閑忙程序，簡單直接。另外還有詳細的磁盤IO讀寫數據，幫助里也解釋得非常清楚。
再進行一次壓力測試，拿着這份數據，已經絕對性的說明問題了。此時那些大牛把代碼改了一下，性能立馬就上去了，千兆網絡直接成為系統瓶頸。並於Java的控制問題，改用Apache直接編譯程序模塊調用，完成變為可控，問題瞬間解決！
附上iostat的源碼：
轉自：http://hi.baidu.com/higkoo/blog/item/d4f7f822e7871cf8d6cae25e.html
2.iostat來對linux硬盤IO性能進行了解
以前一直不太會用這個參數。現在認真研究了一下iostat，因為剛好有台重要的服務器壓力高,所以放上來分析一下.下面這台就是IO有壓力過大的服務器
# iostat -x 1 10
Linux 2.6.18-92.el5xen 02/03/2009
avg-cpu: %user %nice %system %iowait %steal %idle
1.10 0.00 4.82 39.54 0.07 54.46
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 3.50 0.40 2.50 5.60 48.00 18.48 0.00 0.97 0.97 0.28
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.10 0.30 0.20 2.40 2.40 9.60 0.00 1.60 1.60 0.08
sdf 17.40 0.50 102.00 0.20 12095.20 5.60 118.40 0.70 6.81 2.09 21.36
sdg 232.40 1.90 379.70 0.50 76451.20 19.20 201.13 4.94 13.78 2.45 93.16
rrqm/s: 每秒進行 merge 的讀操作數目。即 delta(rmerge)/s
wrqm/s: 每秒進行 merge 的寫操作數目。即 delta(wmerge)/s
r/s: 每秒完成的讀 I/O 設備次數。即 delta(rio)/s
w/s: 每秒完成的寫 I/O 設備次數。即 delta(wio)/s
rsec/s: 每秒讀扇區數。即 delta(rsect)/s
wsec/s: 每秒寫扇區數。即 delta(wsect)/s
rkB/s: 每秒讀K字節數。是 rsect/s 的一半，因為每扇區大小為512字節。(需要計算)
wkB/s: 每秒寫K字節數。是 wsect/s 的一半。(需要計算)
avgrq-sz: 平均每次設備I/O操作的數據大小 (扇區)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O隊列長度。即 delta(aveq)/s/1000 (因為aveq的單位為毫秒)。
await: 平均每次設備I/O操作的等待時間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次設備I/O操作的服務時間 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的時間用於 I/O 操作，或者說一秒中有多少時間 I/O 隊列是非空的。即 delta(use)/s/1000 (因為use的單位為毫秒)
如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤
可能存在瓶頸。
idle小於70% IO壓力就較大了,一般讀取速度有較多的wait.
同時可以結合vmstat 查看查看b參數(等待資源的進程數)和wa參數(IO等待所占用的CPU時間的百分比,高過30%時IO壓力高)
另外還可以參考
svctm 一般要小於 await (因為同時等待的請求的等待時間被重復計算了)，svctm 的大小一般和磁盤性能有關，CPU/內存的負荷也會對其有影響，請求過多也會間接導致 svctm 的增加。await 的大小一般取決於服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。如果 svctm 比較接近 await，說明 I/O 幾乎沒有等待時間；如果 await 遠大於 svctm，說明 I/O 隊列太長，應用得到的響應時間變慢，如果響應時間超過了用戶可以容許的范圍，這時可以考慮更換更快的磁盤，調整內核 elevator 算法，優化應用，或者升級 CPU。
隊列長度(avgqu-sz)也可作為衡量系統 I/O 負荷的指標，但由於 avgqu-sz 是按照單位時間的平均值，所以不能反映瞬間的 I/O 洪水。
別人一個不錯的例子.(I/O 系統 vs. 超市排隊)
舉一個例子，我們在超市排隊 checkout 時，怎么決定該去哪個交款台呢? 首當是看排的隊人數，5個人總比20人要快吧? 除了數人頭，我們也常常看看前面人購買的東西多少，如果前面有個采購了一星期食品的大媽，那么可以考慮換個隊排了。還有就是收銀員的速度了，如果碰上了連錢都點不清楚的新手，那就有的等了。另外，時機也很重要，可能 5 分鍾前還人滿為患的收款台，現在已是人去樓空，這時候交款可是很爽啊，當然，前提是那過去的 5 分鍾里所做的事情比排隊要有意義 (不過我還沒發現什么事情比排隊還無聊的)。
I/O 系統也和超市排隊有很多類似之處:
r/s+w/s 類似於交款人的總數
平均隊列長度(avgqu-sz)類似於單位時間里平均排隊人的個數
平均服務時間(svctm)類似於收銀員的收款速度
平均等待時間(await)類似於平均每人的等待時間
平均I/O數據(avgrq-sz)類似於平均每人所買的東西多少
I/O 操作率 (%util)類似於收款台前有人排隊的時間比例。
我們可以根據這些數據分析出 I/O 請求的模式，以及 I/O 的速度和響應時間。
下面是別人寫的這個參數輸出的分析
# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
上面的 iostat 輸出表明秒有 28.57 次設備 I/O 操作: 總IO(io)/s = r/s(讀) +w/s(寫) = 1.02+27.55 = 28.57 (次/秒) 其中寫操作占了主體 (w:r = 27:1)。
平均每次設備 I/O 操作只需要 5ms 就可以完成，但每個 I/O 請求卻需要等上 78ms，為什么? 因為發出的 I/O 請求太多 (每秒鍾約 29 個)，假設這些請求是同時發出的，那么平均等待時間可以這樣計算:
平均等待時間 = 單個 I/O 服務時間 * ( 1 + 2 + … + 請求總數-1) / 請求總數
應用到上面的例子: 平均等待時間 = 5ms * (1+2+…+28)/29 = 70ms，和 iostat 給出的78ms 的平均等待時間很接近。這反過來表明 I/O 是同時發起的。
每秒發出的 I/O 請求很多 (約 29 個)，平均隊列卻不長 (只有 2 個 左右)，這表明這 29 個請求的到來並不均勻，大部分時間 I/O 是空閑的。
一秒中有 14.29% 的時間 I/O 隊列中是有請求的，也就是說，85.71% 的時間里 I/O 系統無事可做，所有 29 個 I/O 請求都在142毫秒之內處理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 = 2232.8，表明每秒內的I/O請求總共需要等待2232.8ms。所以平均隊列長度應為 2232.8ms/1000ms = 2.23，而 iostat 給出的平均隊列長度 (avgqu-sz) 卻為 22.35，為什么?! 因為 iostat 中有 bug，avgqu-sz 值應為 2.23，而不是 22.35。
3. linux lsof詳解
lsof簡介
lsof（list open files）是一個列出當前系統打開文件的工具。在linux環境下，任何事物都以文件的形式存在，通過文件不僅僅可以訪問常規數據，還可以訪問網絡連接和硬件。所以如傳輸控制協議 (TCP) 和用戶數據報協議 (UDP) 套接字等，系統在后台都為該應用程序分配了一個文件描述符，無論這個文件的本質如何，該文件描述符為應用程序與基礎操作系統之間的交互提供了通用接口。因為應用程序打開文件的描述符列表提供了大量關於這個應用程序本身的信息，因此通過lsof工具能夠查看這個列表對系統監測以及排錯將是很有幫助的。
lsof使用
lsof輸出信息含義
在終端下輸入lsof即可顯示系統打開的文件，因為 lsof 需要訪問核心內存和各種文件，所以必須以 root 用戶的身份運行它才能夠充分地發揮其功能。
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME init 1 root cwd DIR 3,3 1024 2 / init 1 root rtd DIR 3,3 1024 2 / init 1 root txt REG 3,3 38432 1763452 /sbin/init init 1 root mem REG 3,3 106114 1091620 /lib/libdl-2.6.so init 1 root mem REG 3,3 7560696 1091614 /lib/libc-2.6.so init 1 root mem REG 3,3 79460 1091669 /lib/libselinux.so.1 init 1 root mem REG 3,3 223280 1091668 /lib/libsepol.so.1 init 1 root mem REG 3,3 564136 1091607 /lib/ld-2.6.so init 1 root 10u FIFO 0,15 1309 /dev/initctl
每行顯示一個打開的文件，若不指定條件默認將顯示所有進程打開的所有文件。lsof輸出各列信息的意義如下：
COMMAND：進程的名稱 PID：進程標識符 USER：進程所有者 FD：文件描述符，應用程序通過文件描述符識別該文件。如cwd、txt等 TYPE：文件類型，如DIR、REG等 DEVICE：指定磁盤的名稱 SIZE：文件的大小 NODE：索引節點（文件在磁盤上的標識） NAME：打開文件的確切名稱
其中FD 列中的文件描述符cwd 值表示應用程序的當前工作目錄，這是該應用程序啟動的目錄，除非它本身對這個目錄進行更改。
txt 類型的文件是程序代碼，如應用程序二進制文件本身或共享庫，如上列表中顯示的 /sbin/init 程序。其次數值表示應用
程序的文件描述符，這是打開該文件時返回的一個整數。如上的最后一行文件/dev/initctl，其文件描述符為 10。u 表示該
文件被打開並處於讀取/寫入模式，而不是只讀 ® 或只寫 (w) 模式。同時還有大寫 的W 表示該應用程序具有對整個文件的寫
鎖。該文件描述符用於確保每次只能打開一個應用程序實例。初始打開每個應用程序時，都具有三個文件描述符，從 0 到 2，
分別表示標准輸入、輸出和錯誤流。所以大多數應用程序所打開的文件的 FD 都是從 3 開始。
與 FD 列相比，Type 列則比較直觀。文件和目錄分別稱為 REG 和 DIR。而CHR 和 BLK，分別表示字符和塊設備；
或者 UNIX、FIFO 和 IPv4，分別表示 UNIX 域套接字、先進先出 (FIFO) 隊列和網際協議 (IP) 套接字。
lsof常用參數
lsof 常見的用法是查找應用程序打開的文件的名稱和數目。可用於查找出某個特定應用程序將日志數據記錄到何處，或者正在跟蹤某個問題。
例如，linux限制了進程能夠打開文件的數目。通常這個數值很大，所以不會產生問題，並且在需要時，應用程序可以請求更大的值（直到某
個上限）。如果你懷疑應用程序耗盡了文件描述符，那么可以使用 lsof 統計打開的文件數目，以進行驗證。lsof語法格式是：
lsof ［options］ filename
常用的參數列表：
lsof filename 顯示打開指定文件的所有進程 lsof -a 表示兩個參數都必須滿足時才顯示結果 lsof -c string 顯示COMMAND列中包含指定字符的進程所有打開的文件 lsof -u username 顯示所屬user進程打開的文件 lsof -g gid 顯示歸屬gid的進程情況 lsof +d /DIR/ 顯示目錄下被進程打開的文件 lsof +D /DIR/ 同上，但是會搜索目錄下的所有目錄，時間相對較長 lsof -d FD 顯示指定文件描述符的進程 lsof -n 不將IP轉換為hostname，缺省是不加上-n參數 lsof -i 用以顯示符合條件的進程情況 lsof -i[46] [protocol][@hostname|hostaddr][:service|port] 46 --> IPv4 or IPv6 protocol --> TCP or UDP hostname --> Internet host name hostaddr --> IPv4地址 service --> /etc/service中的 service name (可以不只一個) port --> 端口號 (可以不只一個)
例如： 查看22端口現在運行的情況
# lsof -i :22 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME sshd 1409 root 3u IPv6 5678 TCP *:ssh (LISTEN)
查看所屬root用戶進程所打開的文件類型為txt的文件:
# lsof -a -u root -d txt COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME init 1 root txt REG 3,3 38432 1763452 /sbin/init mingetty 1632 root txt REG 3,3 14366 1763337 /sbin/mingetty mingetty 1633 root txt REG 3,3 14366 1763337 /sbin/mingetty mingetty 1634 root txt REG 3,3 14366 1763337 /sbin/mingetty mingetty 1635 root txt REG 3,3 14366 1763337 /sbin/mingetty mingetty 1636 root txt REG 3,3 14366 1763337 /sbin/mingetty mingetty 1637 root txt REG 3,3 14366 1763337 /sbin/mingetty kdm 1638 root txt REG 3,3 132548 1428194 /usr/bin/kdm X 1670 root txt REG 3,3 1716396 1428336 /usr/bin/Xorg kdm 1671 root txt REG 3,3 132548 1428194 /usr/bin/kdm startkde 2427 root txt REG 3,3 645408 1544195 /bin/bash ... ...
lsof使用實例
一、查找誰在使用文件系統
在卸載文件系統時，如果該文件系統中有任何打開的文件，操作通常將會失敗。那么通過lsof可以找出那些進程在使用當前要卸載的文件系統，如下：
# lsof /GTES11/ COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME bash 4208 root cwd DIR 3,1 4096 2 /GTES11/ vim 4230 root cwd DIR 3,1 4096 2 /GTES11/
在這個示例中，用戶root正在其/GTES11目錄中進行一些操作。一個 bash是實例正在運行，並且它當前的目錄為/GTES11，另一個則顯示的是vim正在編輯/GTES11下的文件。要成功地卸載/GTES11，應該在通知用戶以確保情況正常之后，中止這些進程。 這個示例說明了應用程序的當前工作目錄非常重要，因為它仍保持着文件資源，並且可以防止文件系統被卸載。這就是為什么大部分守護進程（后台進程）將它們的目錄更改為根目錄、或服務特定的目錄（如 sendmail 示例中的 /var/spool/mqueue）的原因，以避免該守護進程阻止卸載不相關的文件系統。
二、恢復刪除的文件
當Linux計算機受到入侵時，常見的情況是日志文件被刪除，以掩蓋攻擊者的蹤跡。管理錯誤也可能導致意外刪除重要的文件，比如在清理舊日志時，意外地刪除了數據庫的活動事務日志。有時可以通過lsof來恢復這些文件。
當進程打開了某個文件時，只要該進程保持打開該文件，即使將其刪除，它依然存在於磁盤中。這意味着，進程並不知道文件已經被刪除，它仍然可以向打開該文件時提供給它的文件描述符進行讀取和寫入。除了該進程之外，這個文件是不可見的，因為已經刪除了其相應的目錄索引節點。
在/proc 目錄下，其中包含了反映內核和進程樹的各種文件。/proc目錄掛載的是在內存中所映射的一塊區域，所以這些文件和目錄並不存在於磁盤中，因此當我們對這些文件進行讀取和寫入時，實際上是在從內存中獲取相關信息。大多數與 lsof 相關的信息都存儲於以進程的 PID 命名的目錄中，即 /proc/1234 中包含的是 PID 為 1234 的進程的信息。每個進程目錄中存在着各種文件，它們可以使得應用程序簡單地了解進程的內存空間、文件描述符列表、指向磁盤上的文件的符號鏈接和其他系統信息。lsof 程序使用該信息和其他關於內核內部狀態的信息來產生其輸出。所以lsof 可以顯示進程的文件描述符和相關的文件名等信息。也就是我們通過訪問進程的文件描述符可以找到該文件的相關信息。
當系統中的某個文件被意外地刪除了，只要這個時候系統中還有進程正在訪問該文件，那么我們就可以通過lsof從/proc目錄下恢復該文件的內容。 假如由於誤操作將/var/log/messages文件刪除掉了，那么這時要將/var/log/messages文件恢復的方法如下：
首先使用lsof來查看當前是否有進程打開/var/logmessages文件，如下：
# lsof |grep /var/log/messages syslogd 1283 root 2w REG 3,3 5381017 1773647 /var/log/messages (deleted)
從上面的信息可以看到 PID 1283（syslogd）打開文件的文件描述符為 2。同時還可以看到/var/log/messages已經標記被刪除了。因此我們可以在 /proc/1283/fd/2 （fd下的每個以數字命名的文件表示進程對應的文件描述符）中查看相應的信息，如下：
# head -n 10 /proc/1283/fd/2 Aug 4 13:50:15 holmes86 syslogd 1.4.1: restart. Aug 4 13:50:15 holmes86 kernel: klogd 1.4.1, log source = /proc/kmsg started. Aug 4 13:50:15 holmes86 kernel: Linux version 2.6.22.1-8 (root@everestbuilder.linux-ren.org) (gcc version 4.2.0) #1 SMP Wed Jul 18 11:18:32 EDT 2007 Aug 4 13:50:15 holmes86 kernel: BIOS-provided physical RAM map: Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 0000000000000000 - 000000000009f000 (usable) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 0000000000100000 - 000000001f7d3800 (usable) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 000000001f7d3800 - 0000000020000000 (reserved) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 00000000e0000000 - 00000000f0007000 (reserved) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 00000000f0008000 - 00000000f000c000 (reserved)
從上面的信息可以看出，查看 /proc/8663/fd/15 就可以得到所要恢復的數據。如果可以通過文件描述符查看相應的數據，那么就可以使用 I/O 重定向將其復制到文件中，如:
cat /proc/1283/fd/2 > /var/log/messages
對於許多應用程序，尤其是日志文件和數據庫，這種恢復刪除文件的方法非常有用。
4. Linux iostat監測IO狀態[轉]
Linux系統出現了性能問題，一般我們可以通過top、iostat、free、vmstat等命令 來查看初步定位問題。其中iostat可以給我們提供豐富的IO狀態數據。
1. 基本使用
參數 -d 表示，顯示設備（磁盤）使用狀態；-k某些使用block為單位的列強制使用Kilobytes為單位；1 10表示，數據顯示每隔1秒刷新一次，共顯示10次。
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 39.29 21.14 1.44 441339807 29990031
sda1 0.00 0.00 0.00 1623 523
sda2 1.32 1.43 4.54 29834273 94827104
sda3 6.30 0.85 24.95 17816289 520725244
sda5 0.85 0.46 3.40 9543503 70970116
sda6 0.00 0.00 0.00 550 236
sda7 0.00 0.00 0.00 406 0
sda8 0.00 0.00 0.00 406 0
sda9 0.00 0.00 0.00 406 0
sda10 60.68 18.35 71.43 383002263 1490928140
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 327.55 5159.18 102.04 5056 100
sda1 0.00 0.00 0.00 0 0
tps：該設備每秒的傳輸次數（Indicate the number of transfers per second that were issued to the device.）。“一次傳輸”意思是“一次I/O請求”。多個邏輯請求可能會被合並為“一次I/O請求”。“一次傳輸”請求的大小是未知的。
kB_read/s：每秒從設備（drive expressed）讀取的數據量；kB_wrtn/s：每秒向設備（drive expressed）寫入的數據量；kB_read：讀取的總數據量；kB_wrtn：寫入 的總數量數據量；這些單位都為Kilobytes。
上面的例子中，我們可以看到磁盤sda以及它的各個分區的統計數據，當時統計的磁盤總TPS是39.29，下面是各個分區的TPS。（因為是瞬間 值，所以總TPS並不嚴格等於各個分區TPS的總和）
2. -x 參數
使用-x參數我們可以獲得更多統計信息。
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 1.56 28.31 7.80 31.49 42.51 2.92 21.26 1.46 1.16 0.03 0.79 2.62 10.28
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 2.00 20.00 381.00 7.00 12320.00 216.00 6160.00 108.00 32.31 1.75 4.50 2.17 84.20
rrqm/s：每秒這個設備相關的讀取請求有多少被Merge了（當系統調用需要讀取數據的 時候，VFS將請求發到各個FS，如果FS發現不同的讀取請求讀取的是相同Block的數據，FS會將這個請求合並Merge）；wrqm/s：每秒這個 設備相關的寫入請求有多少被Merge了。
rsec/s：每秒讀取的扇區數；wsec/： 每秒寫入的扇區數。r/s：The number of read requests that were issued to the device per second；w/s：The number of write requests that were issued to the device per second；
await：每一個IO請求的處理的平均時間（單位是微秒）。這里可以理解為IO的響應時 間，一般地系統IO響應時間應該低於5ms，如果大於10ms就比較大了。
%util：在統計時間內所有處理IO時間，除以總共統計時間。例如，如果統計間隔1秒，該 設備有0.8秒在處理IO，而0.2秒閑置，那么該設備的%util = 0.8/1 = 80%，所以該參數暗示了設備的繁忙程度。一般地，如果該參數是100%表示設備已經接近滿負荷運行了（當然如果是多磁盤，即使%util是100%，因 為磁盤的並發能力，所以磁盤使用未必就到了瓶頸）。
3. -c 參數
iostat還可以用來獲取cpu部分狀態值：
avg-cpu: %user %nice %sys %iowait %idle
1.98 0.00 0.35 11.45 86.22
avg-cpu: %user %nice %sys %iowait %idle
1.62 0.00 0.25 34.46 63.67
4. 常見用法
iostat -d -x -k 1 10 #查看設備使用率（%util）、響應時間（await）
iostat -c 1 10 #查看cpu狀態
5. 實例分析
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda10 60.72 18.95 71.53 395637647 1493241908
sda10 299.02 4266.67 129.41 4352 132
sda10 483.84 4589.90 4117.17 4544 4076
sda10 218.00 3360.00 100.00 3360 100
sda10 546.00 8784.00 124.00 8784 124
sda10 827.00 13232.00 136.00 13232 136
上面看到，磁盤每秒傳輸次數平均約400；每秒磁盤讀取約5MB，寫入約1MB。
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 1.56 28.31 7.84 31.50 43.65 3.16 21.82 1.58 1.19 0.03 0.80 2.61 10.29
sda 1.98 24.75 419.80 6.93 13465.35 253.47 6732.67 126.73 32.15 2.00 4.70 2.00 85.25
sda 3.06 41.84 444.90 54.08 14204.08 2048.98 7102.04 1024.49 32.57 2.10 4.21 1.85 92.24
可以看到磁盤的平均響應時間<5ms，磁盤使用率>80。磁盤響應正常，但是已經很繁忙了。
參考文獻：
- Linux man iostat
- How Linux iostat computes its results
- Linux iostat
http://blog.csdn.net/AE86_FC/archive/2010/02/03/5284112.aspx
最近要對分布式集群做一些性能測試，其中一個很重要的項就是測試hadoop分布式集群在支持多磁盤輪轉 寫入的時候在各種磁盤配置的情況下的讀寫性能，如 在RAID0,RAID5和JBOD情況下的磁盤性能，所以linux下的iostat命令就在產生report的腳本中非常有用，特此記錄下iostat命令的一些使用筆 記：
[命令:] iostat [-c|-d] [-k] [-t] [間隔描述] [檢測次數]
參 數：
-c : 僅顯示cpu的狀態
-d : 僅顯示存儲設備的狀態，不可以和-c一起使用
-k : 默認顯示的是讀入讀出的block信息，用-k可以改成KB大小來顯示
-t : 顯示日期
-p device | ALL : device為某個設備或者某個分區，如果使用ALL，就表示要顯示所有分區和設備的信息
顯示示例：
avg-cpu: %user %nice %sys %iowait %idle
4.55 0.00 0.63 0.26 94.56
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
cciss/c0d0 30.11 68.20 67.13 1232784060 1213452142
cciss/c0d0p1 0.00 0.00 0.00 2531 2
cciss/c0d0p2 83.78 68.18 67.11 1232572011 1213204536
dm-0 1.06 0.60 4.07 10873201 73555720
dm-1 82.50 67.42 62.23 1218704309 1124966656
dm-2 0.21 0.18 0.83 3199605 14929540
dm-3 0.00 0.00 0.00 372 224
以上顯示分為上下兩個部 分，上半部分顯示CPU的信息，下面的數 據顯示存儲設備的相關數據，它的數據意義如下：
tps：平均每秒鍾的傳送次數，與數據傳輸“次數”相關，非容 量
kB_read/s：啟動到現在的平均讀取單位
kB_wrtn/s：啟動到現在的平均寫入單位
kB_read：啟動到現在總共 讀出來的文件單位
kB_wrtn： 啟動到現在總共寫入的文件單位
如果想要對iostat檢查多此，每次之間的間隔一定數量的秒數，這樣就可以查看每幾秒鍾之內的io統計數 據，這對性能的測試才具有實際意義：
$> iostat -d 2 3
表示沒量秒鍾檢查一次，一共檢查三次
avg-cpu: %user %nice %sys %iowait %idle
4.55 0.00 0.63 0.26 94.56
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
cciss/c0d0 30.11 68.20 67.13 1232900288 1213456210
cciss/c0d0p1 0.00 0.00 0.00 2531 2
cciss/c0d0p2 83.78 68.19 67.11 1232688239 1213208604
dm-0 1.06 0.60 4.07 10873201 73558008
dm-1 82.50 67.42 62.23 1218820537 1124967604
dm-2 0.21 0.18 0.83 3199605 14930372
dm-3 0.00 0.00 0.00 372 224
avg-cpu: %user %nice %sys %iowait %idle
0.00 0.00 0.63 0.00 99.37
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
cciss/c0d0 1.02 0.00 63.27 0 124
cciss/c0d0p1 0.00 0.00 0.00 0 0
cciss/c0d0p2 15.82 0.00 63.27 0 124
dm-0 15.82 0.00 63.27 0 124
dm-1 0.00 0.00 0.00 0 0
dm-2 0.00 0.00 0.00 0 0
dm-3 0.00 0.00 0.00 0 0
avg-cpu: %user %nice %sys %iowait %idle
0.00 0.00 0.32 0.00 99.68
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
cciss/c0d0 3.06 0.00 26.53 0 52
cciss/c0d0p1 0.00 0.00 0.00 0 0
cciss/c0d0p2 6.63 0.00 26.53 0 52
dm-0 0.00 0.00 0.00 0 0
dm-1 6.63 0.00 26.53 0 52
dm-2 0.00 0.00 0.00 0 0
dm-3 0.00 0.00 0.00 0 0
其中每一次的統計都是上 一次的統計時間到這次的統計時間之間的統計數據
5. 如何查看進程 IO 讀寫情況？
2009年08月26日 | 標簽:linux,python| 作者：vpsee
Linux Kernel 2.6.20 以上的內核支持進程 IO 統計，可以用類似 iotop 這樣的工具來監測每個進程對 IO 操作的情況，就像用 top 來實時查看進程內存、CPU 等占用情況那樣。但是對於 2.6.20 以下的 Linux 內核版本就沒那么幸運了，根據Stack Overflow 的這篇回帖給出的方法，VPSee 寫了一個簡單的 Python 腳本用來在 linux kernel < 2.6.20 下打印進程 IO 狀況。
Kernel < 2.6.20
這個腳本的想法很簡單，把 dmesg 的結果重定向到一個文件后再解析出來，每隔1秒鍾打印一次進程 IO 讀寫的統計信息，執行這個腳本需要 root：
#!/usr/bin/python
# Monitoring per-process disk I/O activity
# written by http://www.vpsee.com
import sys, os, time, signal, re
class DiskIO:
def __init__(self, pname=None, pid=None, reads=0, writes=0):
self.pname = pname
self.pid = pid
self.reads = 0
self.writes = 0
def main():
argc = len(sys.argv)
if argc != 1:
print "usage: ./iotop"
sys.exit(0)
if os.getuid() != 0:
print "must be run as root"
sys.exit(0)
signal.signal(signal.SIGINT, signal_handler)
os.system('echo 1 > /proc/sys/vm/block_dump')
print "TASK PID READ WRITE"
while True:
os.system('dmesg -c > /tmp/diskio.log')
l = []
f = open('/tmp/diskio.log', 'r')
line = f.readline()
while line:
m = re.match(\
'^(\S+)\((\d+)\): (READ|WRITE) block (\d+) on (\S+)', line)
if m != None:
if not l:
l.append(DiskIO(m.group(1), m.group(2)))
line = f.readline()
continue
found = False
for item in l:
if item.pid == m.group(2):
found = True
if m.group(3) == "READ":
item.reads = item.reads + 1
elif m.group(3) == "WRITE":
item.writes = item.writes + 1
if not found:
l.append(DiskIO(m.group(1), m.group(2)))
line = f.readline()
time.sleep(1)
for item in l:
print "%-10s %10s %10d %10d" % \
(item.pname, item.pid, item.reads, item.writes)
def signal_handler(signal, frame):
os.system('echo 0 > /proc/sys/vm/block_dump')
sys.exit(0)
if __name__=="__main__":
main()
Kernel >= 2.6.20
如果想用 iotop 來實時查看進程 IO 活動狀況的話，需要下載和升級新內核（2.6.20 或以上版本）。編譯新內核時需要打開 TASK_DELAY_ACCT 和 TASK_IO_ACCOUNTING 選項。解壓內核后進入配置界面：
# tar jxvf linux-2.6.30.5.tar.bz2 # mv linux-2.6.30.5 /usr/src/ # cd /usr/src/linux-2.6.30.5 # make menuconfig
選擇 Kernel hacking –> Collect scheduler debugging info 和 Collect scheduler statistics，保存內核后編譯內核：
# make; make modules; make modules_install; make install
修改 grub，確認能正確啟動新內核：
# vi /boot/grub/menu.lst
出了新內核外，iotop 還需要 Python 2.5 或以上才能運行，所以如果當前 Python 是 2.4 的話需要下載和安裝最新的 Python 包。這里使用源代碼編譯安裝：
# tar jxvf Python-2.6.2.tar.bz2 # cd Python-2.6.2 # ./configure # make; make install
別忘了下載 setuptools：
# mv setuptools-0.6c9-py2.6.egg.sh setuptools-0.6c9-py2.6.egg # sh setuptools-0.6c9-py2.6.egg
更多信息
如果想知道更多關於 block_dump 的信息，可以看看這篇監測 Linux 進程的實時 IO 情況。使用 block_dump 的時候，最好能關掉 klogd 進程