TOP 觀察：IO等待所占用的CPU時間的百分比，高過30%時IO壓力高其次、用iostat -x 1 10

[root@controller ~]#iostat -d -k 1 10Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtnsda 19.00 0.00 112.00 0 112sda1 0.00 0.00 0.00 0 0sda2 0.00 0.00 0.00 0 0sda3 0.00 0.00 0.00 0 0sda4 0.00 0.00 0.00 0 0sda5 3.00 0.00 16.00 0 16sda6 0.00 0.00 0.00 0 0sda7 16.00 0.00 96.00 0 96

tps:該設備每秒的傳輸次數，一次傳輸的意思是“一次I/O請求”

kB_read/s：每秒從設備讀取的數據量 kB_wrtn/s：每秒向設備寫入的數據量 kB_read：讀取的總數據量 kB_wrtn ：寫入的總數量數據量

使用-x獲得更多信息

使用-x獲得更多信息

查看設備使用率（%util）、響應時間（await）

[root@controller ~]#iostat -d -x -k 1 10Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %utilsda0.00 22.00 0.00 18.00 0.00 160.00 17.78 0.07 3.78 3.78 6.80sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00sda3 0.00 15.00 0.00 2.00 0.00 68.00 68.00 0.01 6.50 6.50 1.30sda4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00sda5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00sda6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00sda7 0.00 7.00 0.00 16.00 0.00 92.00 11.50 0.06 3.44 3.44 5.50 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參數()

另外還可以參考

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的速度和響應時間。

%util：在統計時間內所有處理IO時間，除以總共統計時間。例如，如果統計間隔1秒，該設備有0.8秒在處理IO，而0.2秒閑置，那么該設備的%util = 0.8/1 = 80%，所以該參數暗示了設備的繁忙程度。一般地，如果該參數是100%表示設備已經接近滿負荷運行了（當然如果是多磁盤，即使%util是100%，因為磁盤的并發能力，所以磁盤使用未必就到了瓶頸）。)

部署一個程序時（我測試的是一個實時上傳日志的程序），對系統的cpu、內存、io等都要有所考慮，保證系統高效的運行。

如果程序本身處理的包特別小，事件很多，壓力大且沒有間隔的話，占用CPU的資源會很多

如果用磁盤緩存，不用內存緩存的話，能夠支持斷點重傳，保證數據的可靠性上傳，如突然斷電等情況，存入磁盤緩存的數據等到恢復后會依然上傳，而不會丟失，但是相對的也會增加讀寫磁盤的次數，如果數據量比較小，速度還是可以忍受的。

下面是別人寫的這個參數輸出的分析

# iostat -x 1avg-cpu: %user %nice %sys %idle16.24 0.00 4.31 79.44Device: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。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持好吧啦網。