top 觀察：io等待所占用的cpu時間的百分比，高過30%時io壓力高其次、用iostat -x 1 10
[root@controller ~]#iostat -d -k 1 10
device: tps kb_read/s kb_wrtn/s kb_read kb_wrtn
sda 19.00 0.00 112.00 0 112
sda1 0.00 0.00 0.00 0 0
sda2 0.00 0.00 0.00 0 0
sda3 0.00 0.00 0.00 0 0
sda4 0.00 0.00 0.00 0 0
sda5 3.00 0.00 16.00 0 16
sda6 0.00 0.00 0.00 0 0
sda7 16.00 0.00 96.00 0 96
tps:該裝置每秒的傳輸次數，一次傳輸的意思是「一次i/o請求」
使用-x獲得更多資訊
使用-x獲得更多資訊
檢視裝置使用率（%util）、響應時間（await）
[root@controller ~]#iostat -d -x -k 1 10
device: rrqm/s wrqm/s r/s w/s rkb/s wkb/s **grq-sz **gqu-sz await svctm %util
sda 0.00 22.00 0.0程式設計客棧0 18.00 0.00 160.00 17.78 0.07 3.78 3.78 6.80
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda3 0.00 15.00 0.00 2.00 0.00 68.00 68.00 0.01 6.50 6.50 1.30
sda4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda7 0.00 7.00 0.00 16.00 0.00 92.00 11.50 0.06 3.44 3.44 5.50
如果%util接近100%，說明fgmoihi產生的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。
佇列長度(**gqu-sz)也可作為衡量系統i/o負荷的指標，但由於**gqu-sz是按照單位時間的平均值，所以不能反映瞬間的i/o洪水。
別人乙個不錯的例子.(i/o系統vs.超市排隊)
舉 乙個例子，我們在超市排隊checkout時，怎麼決定該去哪個交款臺呢?首當是看排的隊人數，5個人總比20人要快吧? 除了數人頭，我們也常常看看前面人購買的東西多少，如果前面有個採購了一星期食品的大媽，那麼可以考慮換個隊排了。還有就是收銀員的速度了，如果碰上了連 錢都點不清楚的新手，那就有的等了。另外，時機也很重要，可能5 分鐘前還人滿為患的收款臺，現在已是人去樓空，這時候交款可是很爽啊，當然，前提是那過去的5分鐘裡所做的事情比排隊要有意義 (不過我還沒發現什麼事情比排隊還無聊的)。
i/o系統也和超市排隊有很多類似之處:
我們可以根據這些資料分析出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 1
**g-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 **grq-sz **gqu-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給出的平均佇列長度(**gqu-sz)卻為22.35，為什麼?!因為 iostat中有bug，**gqu-sz值應為2.23，而不是22.35。
本文標題: 如何使用iostat檢視linux硬碟io效能
本文位址:
iostat檢視系統I O負載
iostat 選項 引數 c 僅顯示cpu使用情況 d 僅顯示裝置利用率 k 顯示狀態以千位元組每秒為單位，而不使用塊每秒 m 顯示狀態以兆位元組每秒為單位 p 僅顯示塊裝置和所有被使用的其他分割槽的狀態 t 顯示每個報告產生時的時間 v 顯示版號並退出 x 顯示擴充套件狀態。次數 顯示報告的次數。...
559 使用iostat檢視磁碟的讀寫情況
全部學習彙總 前面，安裝並使用過iotop，基本能夠看得出磁碟的讀寫情況，實時顯示。今晚上看到了乙個新命令，iostat，測試了一下老母雞的armbian是內建的。我想在樹莓派上用一下發現沒有這個名，嘗試做了安裝。安裝需要通過sudo apt get install sysstat，效果如下 之後，...
iostat檢視伺服器io
iostat 檢視伺服器實時io 說明 cpu屬性值說明 user cpu處在使用者模式下的時間百分比。nice cpu處在帶nice值的使用者模式下的時間百分比。system cpu處在系統模式下的時間百分比。iowait cpu等待輸入輸出完成時間的百分比。steal 管理程式維護另乙個虛擬處理...