[轉載]容易被誤讀的IOSTAT

http://linuxperf.com/?p=156

容易被誤讀的IOSTAT

2016/11/29 VMUNIX

iostat(1)是在Linux系統上查看I/O性能最基本的工具，然而對於那些熟悉其它UNIX系統的人來講它是很容易被誤讀的。好比在HP-UX上 avserv（至關於Linux上的 svctm）是最重要的I/O指標，反映了硬盤設備的性能，它是指I/O請求從SCSI層發出、到I/O完成以後返回SCSI層所消耗的時間，不包括在SCSI隊列中的等待時間，因此avserv體現了硬盤設備處理I/O的速度，又被稱爲disk service time，若是avserv很大，那麼確定是硬件出問題了。然而Linux上svctm的含義大相徑庭，事實上在iostat(1)和sar(1)的man page上都說了不要相信svctm，該指標將被廢棄：
「Warning! Do not trust this field any more. This field will be removed in a future sysstat version.」

在Linux上，每一個I/O的平均耗時是用await表示的，但它不能反映硬盤設備的性能，由於await不只包括硬盤設備處理I/O的時間，還包括了在隊列中等待的時間。I/O請求在隊列中的時候還沒有發送給硬盤設備，即隊列中的等待時間不是硬盤設備消耗的，因此說await體現不了硬盤設備的速度，內核的問題好比I/O調度器什麼的也有可能致使await變大。那麼有沒有哪一個指標能夠衡量硬盤設備的性能呢？很是遺憾的是，iostat(1)和sar(1)都沒有，這是由於它們所依賴的/proc/diskstats不提供這項數據。要真正理解iostat的輸出結果，應該從理解/proc/diskstats開始。

 

1 2 3 4 5 6 7 8 9

# cat /proc/diskstats    8       0 sda 239219 1806 37281259 2513275 904326 88832 50268824 26816609 0 4753060 29329105    8       1 sda1 338 0 53241 6959 154 0 5496 3724 0 6337 10683    8       2 sda2 238695 1797 37226458 2504489 620322 88832 50263328 25266599 0 3297988 27770221    8      16 sdb 1009117 481 1011773 127319 0 0 0 0 0 126604 126604    8      17 sdb1 1008792 480 1010929 127078 0 0 0 0 0 126363 126363 253       0 dm-0 1005 0 8040 15137 30146 0 241168 2490230 0 30911 2505369 253       1 dm-1 192791 0 35500457 2376087 359162 0 44095600 22949466 0 2312433 25325563 253       2 dm-2 47132 0 1717329 183565 496207 0 5926560 7348763 0 2517753 7532688

/proc/diskstats有11個字段，如下內核文檔解釋了它們的含義https://www.kernel.org/doc/Documentation/iostats.txt，我從新表述了一下，注意除了字段#9以外都是累計值，從系統啓動以後一直累加：

1. (rd_ios)讀操做的次數。
2. (rd_merges)合併讀操做的次數。若是兩個讀操做讀取相鄰的數據塊時，能夠被合併成一個，以提升效率。合併的操做一般是I/O scheduler（也叫elevator）負責的。
3. (rd_sectors)讀取的扇區數量。
4. (rd_ticks)讀操做消耗的時間（以毫秒爲單位）。每一個讀操做從__make_request()開始計時，到end_that_request_last()爲止，包括了在隊列中等待的時間。
5. (wr_ios)寫操做的次數。
6. (wr_merges)合併寫操做的次數。
7. (wr_sectors)寫入的扇區數量。
8. (wr_ticks)寫操做消耗的時間（以毫秒爲單位）。
9. (in_flight)當前未完成的I/O數量。在I/O請求進入隊列時該值加1，在I/O結束時該值減1。
   注意：是I/O請求進入隊列時，而不是提交給硬盤設備時。
10. (io_ticks)該設備用於處理I/O的天然時間(wall-clock time)。
    請注意io_ticks與rd_ticks(字段#4)和wr_ticks(字段#8)的區別，rd_ticks和wr_ticks是把每個I/O所消耗的時間累加在一塊兒，由於硬盤設備一般能夠並行處理多個I/O，因此rd_ticks和wr_ticks每每會比天然時間大。而io_ticks表示該設備有I/O（即非空閒）的時間，不考慮I/O有多少，只考慮有沒有。在實際計算時，字段#9(in_flight)不爲零的時候io_ticks保持計時，字段#9(in_flight)爲零的時候io_ticks中止計時。
11. (time_in_queue)對字段#10(io_ticks)的加權值。字段#10(io_ticks)是天然時間，不考慮當前有幾個I/O，而time_in_queue是用當前的I/O數量（即字段#9 in-flight）乘以天然時間。雖然該字段的名稱是time_in_queue，但並不真的只是在隊列中的時間，其中還包含了硬盤處理I/O的時間。iostat在計算avgqu-sz時會用到這個字段。

iostat(1)是以/proc/diskstats爲基礎計算出來的，由於/proc/diskstats並未把隊列等待時間和硬盤處理時間分開，因此凡是以它爲基礎的工具都不可能分別提供disk service time以及與queue有關的值。
注：下面的公式中「Δ」表示兩次取樣之間的差值，「Δt」表示採樣週期。

• tps：每秒I/O次數=[(Δrd_ios+Δwr_ios)/Δt]
  • r/s：每秒讀操做的次數=[Δrd_ios/Δt]
  • w/s：每秒寫操做的次數=[Δwr_ios/Δt]
• rkB/s：每秒讀取的千字節數=[Δrd_sectors/Δt]*[512/1024]
• wkB/s：每秒寫入的千字節數=[Δwr_sectors/Δt]*[512/1024]
• rrqm/s：每秒合併讀操做的次數=[Δrd_merges/Δt]
• wrqm/s：每秒合併寫操做的次數=[Δwr_merges/Δt]
• avgrq-sz：每一個I/O的平均扇區數=[Δrd_sectors+Δwr_sectors]/[Δrd_ios+Δwr_ios]
• avgqu-sz：平均未完成的I/O請求數量=[Δtime_in_queue/Δt]
  （手冊上說是隊列裏的平均I/O請求數量，更恰當的理解應該是平均未完成的I/O請求數量。）
• await：每一個I/O平均所需的時間=[Δrd_ticks+Δwr_ticks]/[Δrd_ios+Δwr_ios]
  （不只包括硬盤設備處理I/O的時間，還包括了在kernel隊列中等待的時間。）

   

  • r_await：每一個讀操做平均所需的時間=[Δrd_ticks/Δrd_ios]
    不只包括硬盤設備讀操做的時間，還包括了在kernel隊列中等待的時間。
  • w_await：每一個寫操做平均所需的時間=[Δwr_ticks/Δwr_ios]
    不只包括硬盤設備寫操做的時間，還包括了在kernel隊列中等待的時間。
• %util：該硬盤設備的繁忙比率=[Δio_ticks/Δt]
  表示該設備有I/O（即非空閒）的時間比率，不考慮I/O有多少，只考慮有沒有。
• svctm：已被廢棄的指標，沒什麼意義，svctm=[util/tput]

對iostat(1)的恰當解讀有助於正確地分析問題，咱們結合實際案例進一步討論。

關於rrqm/s和wrqm/s

前面講過，若是兩個I/O操做發生在相鄰的數據塊時，它們能夠被合併成一個，以提升效率，合併的操做一般是I/O scheduler（也叫elevator）負責的。

如下案例對許多硬盤設備執行一樣的壓力測試，結果唯有sdb比其它硬盤都更快一些，但是硬盤型號都同樣，爲何sdb的表現不同？

能夠看到其它硬盤的rrqm/s都爲0，而sdb不是，就是說發生了I/O合併，因此效率更高，r/s和rMB/s都更高，咱們知道I/O合併是內核的I/O scheduler（elevator）負責的，因而檢查了sdb的/sys/block/sdb/queue/scheduler，發現它與別的硬盤用了不一樣的I/O scheduler，因此表現也不同。

%util與硬盤設備飽和度

%util表示該設備有I/O（即非空閒）的時間比率，不考慮I/O有多少，只考慮有沒有。因爲現代硬盤設備都有並行處理多個I/O請求的能力，因此%util即便達到100%也不意味着設備飽和了。舉個簡化的例子：某硬盤處理單個I/O須要0.1秒，有能力同時處理10個I/O請求，那麼當10個I/O請求依次順序提交的時候，須要1秒才能所有完成，在1秒的採樣週期裏%util達到100%；而若是10個I/O請求一次性提交的話，0.1秒就所有完成，在1秒的採樣週期裏%util只有10%。可見，即便%util高達100%，硬盤也仍然有可能還有餘力處理更多的I/O請求，即沒有達到飽和狀態。那麼iostat(1)有沒有哪一個指標能夠衡量硬盤設備的飽和程度呢？很遺憾，沒有。

await多大才算有問題

await是單個I/O所消耗的時間，包括硬盤設備處理I/O的時間和I/O請求在kernel隊列中等待的時間，正常狀況下隊列等待時間能夠忽略不計，姑且把await看成衡量硬盤速度的指標吧，那麼多大算是正常呢？
對於SSD，從0.0x毫秒到1.x毫秒不等，具體看產品手冊；
對於機械硬盤，能夠參考如下文檔中的計算方法：
http://cseweb.ucsd.edu/classes/wi01/cse102/sol2.pdf
大體來講一萬轉的機械硬盤是8.38毫秒，包括尋道時間、旋轉延遲、傳輸時間。

在實踐中，要根據應用場景來判斷await是否正常，若是I/O模式很隨機、I/O負載比較高，會致使磁頭亂跑，尋道時間長，那麼相應地await要估算得大一些；若是I/O模式是順序讀寫，只有單一進程產生I/O負載，那麼尋道時間和旋轉延遲均可以忽略不計，主要考慮傳輸時間，相應地await就應該很小，甚至不到1毫秒。在如下實例中，await是7.50毫秒，彷佛並不大，但考慮到這是一個dd測試，屬於順序讀操做，並且只有單一任務在該硬盤上，這裏的await應該不到1毫秒纔算正常：

 

1 2	Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util sdg               0.00     0.00  133.00    0.00  2128.00     0.00    16.00     1.00    7.50   7.49  99.60

對磁盤陣列來講，由於有硬件緩存，寫操做不等落盤就算完成，因此寫操做的service time大大加快了，若是磁盤陣列的寫操做不在一兩個毫秒之內就算慢的了；讀操做則未必，不在緩存中的數據仍然須要讀取物理硬盤，單個小數據塊的讀取速度跟單盤差很少。