linux磁盤IO查看(iostat)

##############

#

#    操作

#

##############

# 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的單位為毫秒)

##############

#

#    分析

#

##############

1.

如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。

2.

如果 idle 小於 70% IO壓力就較大了,一般讀取速度有較多的wait。

3.同時可以結合

vmstat 查看查看b參數(等待資源的進程數)和wa參數(IO等待所占用的CPU時間的百分比,高過30%時IO壓力高)

4.另外還可以參考

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.2      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。

vmstat監視內存使用情況

vmstat是Virtual MeomoryStatistics(虛擬內存統計)的縮寫，可對操作系統的虛擬內存、進程、CPU活動進行監視。它是對系統的整體情況進行統計，不足之處是無法對某個進程進行深入分析。

vmstat的語法如下：

vmstat [-V] [-n] [delay [count]]

-V表示打印出版本信息；

-n表示在周期性循環輸出時，輸出的頭部信息僅顯示一次；

delay是兩次輸出之間的延遲時間；

count是指按照這個時間間隔統計的次數。

[root@yufei ~]# vmstat

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----

r b swpd free buff cache si so bi bo in cs us sy id wa st

0 0 4116 38560 24456 90224 5 11 595 71 96 134 2 2 88 8 0

結果參數說明：

Procs

r:等待執行的任務數

b:處在非中斷睡眠狀態的進程數

展示了正在執行和等待CPU資源的任務個數。當這個值超過了CPU數目，就會出現CPU瓶頸了

Memory

swpd:正在使用的swap大小單位K

free:空閑的內存空間

buff:已使用的buff大小，對塊設備的讀寫進行緩沖

cache:已使用的cache大小，文件系統的cache

inact:

active:

Swap

si:交換內存使用，由磁盤調入內存

so:交換內存使用，由內存調入磁盤

IO

bi:從塊設備讀入的數據總量(讀磁盤) (KB/s)

bo:寫入到塊設備的數據總理(寫磁盤) (KB/s)

System

in:每秒產生的中斷次數

cs:每秒產生的上下文切換次數

上面這2個值越大，會看到由內核消耗的CPU時間會越多

CPU

us:用戶進程消耗的CPU時間百分比

us 的值比較高時，說明用戶進程消耗的CPU時間多，但是如果長期超過50% 的使用，那么我們就該考慮優化程序算法或者進行加速了

sy:內核進程消耗的CPU時間百分比

sy 的值高時，說明系統內核消耗的CPU資源多，這並不是良性的表現，我們應該檢查原因。

id:空閑

wa:IO等待消耗的CPU時間百分比

wa 的值高時，說明IO等待比較嚴重，這可能是由於磁盤大量作隨機訪問造成，也有可能是磁盤的帶寬出現瓶頸(塊操作)