iostat工具分析 I/O 瓶頸

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開始。

# cat /proc/diskstats
  8      0sda23921918063728125925132759043268883250268824268166090475306029329105
  8      1sda133805324169591540549637240633710683
  8      2sda223869517973722645825044896203228883250263328252665990329798827770221
  8      16sdb1009117481101177312731900000126604126604
  8      17sdb11008792480101092912707800000126363126363
253      0dm-01005080401513730146024116824902300309112505369
253      1dm-11927910355004572376087359162044095600229494660231243325325563
253      2dm-24713201717329183565496207059265607348763025177537532688

/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毫秒才算正常：

對磁碟陣列來說，因為有硬體快取，寫操作不等落盤就算完成，所以寫操作的service time大大加快了，如果磁碟陣列的寫操作不在一兩個毫秒以內就算慢的了；讀操作則未必，不在快取中的資料仍然需要讀取物理硬碟，單個小資料塊的讀取速度跟單盤差不多。

本文永久更新連結地址：http://www.linuxidc.com/Linux/2016-12/138242.htm