容易被誤讀的IOSTAT

- 因為/proc/diskstats並未把佇列等待時間和硬碟處理時間分開，所以凡是以它為基礎的工具都不可能分別提供disk service time以及queue有關的值
- iostat是以/proc/diskstats為基礎計算出來的，
- 每個I/O的平均耗時是用await表示的，但它不能反映硬碟裝置的效能，因為await不僅包括硬碟裝置處理I/O的時間，還包括了在佇列中等待的時
- %util：該硬碟裝置的繁忙比率=[Δio_ticks/Δt]，表示該裝置有I/O（即非空閒）的時間比率，不考慮I/O有多少，只考慮有沒有。太高可能都是順序IO
- %iowait 表示在一個取樣週期內有百分之幾的時間屬於以下情況：CPU空閒、並且有仍未完成的I/O請求

pidstat 計算程式單位時間內的增量


iotop 觀察程式的動態I/O

利用BLKTRACE分析IO效能

使用blktrace需要掛載debugfs：
$ mount -t debugfs debugfs /sys/kernel/debug

利用blktrace把資料記錄在檔案裡,預設的輸出檔名是 sdb.blktrace.<cpu>，每個CPU對應一個檔案。你也可以用-o引數指定自己的輸出檔名。
$ blktrace -d /dev/sdb

利用btt分析blktrace資料。btt是對blktrace資料進行自動分析的工具。
btt不能分析實時資料，只能對blktrace儲存的資料檔案進行分析。使用方法：
把原本按CPU分別儲存的檔案合併成一個，合併後的檔名為sdb.blktrace.bin：
$ blkparse -i sdb -d sdb.blktrace.bin
執行btt對sdb.blktrace.bin進行分析：
$ btt -i sdb.blktrace.bin

我們看到93.7461%的時間消耗在D2C，也就是硬體層，這是正常的，我們說過D2C是衡量硬體效能的指標，
這裡單個IO平均0.129201毫秒，已經是相當快了，單個IO最慢14.246176 毫秒，不算壞。Q2G和G2I都很小，完全正常。
I2D稍微有點大，應該是cfq scheduler的排程策略造成的，你可以試試其它scheduler，比如deadline，比較兩者的差異，然後選擇最適合你應用特點的那個。