【測試】磁盤、CPU統計iostat工具

 下面給出幾個例子：

<code># 顯示一條包括所有的CPU和裝置吞吐率的統計資訊# iostat Linux 2.6.18-53.el5 (cnetos5) 01/21/2008 avg-cpu: %user %nice %system %iowait %steal %idle 0.10 0.04 0.37 0.07 0.00 99.42 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sda 1.44 16.79 10.58 800430 504340 sdb 0.01 0.07 0.00 3314 8 sdc 0.86 8.56 0.00 407892 24 # 每隔5秒顯示一次裝置吞吐率的統計資訊（機關為 塊/s） iostat -d 5 # 每隔5秒顯示一次裝置吞吐率的統計資訊（機關為 KB/s），共輸出3次 iostat -dk 5 3 # 每隔2秒顯示一次 sda 及上面所有分區的統計資訊，共輸出5次 iostat -p sda 2 5 # 每隔2秒顯示一次 sda 和 sdb 兩個裝置的擴充統計資訊，共輸出6次 iostat -x sda sdb 2 6 Linux 2.6.18-53.el5 (cnetos5) 01/21/2008 avg-cpu: %user %nice %system %iowait %steal %idle 0.10 0.04 0.37 0.07 0.00 99.42 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.17 0.84 0.96 0.47 16.67 10.56 19.01 0.01 7.11 1.25 0.18 sdb 0.00 0.00 0.01 0.00 0.07 0.00 5.16 0.00 0.22 0.19 0.00 ………… &gt;iostat -t 5 -x &gt; iostat.out -t是輸出時間和日期，5是代表5秒一次，-x是詳細情況都輸出 主要檢視cpu的idle和磁盤的util</code>

iostat 的輸出項說明

rrqm/s: 每秒對該裝置的讀請求被合并次數，檔案系統會對讀取同塊(block)的請求進行合并

wrqm/s: 每秒對該裝置的寫請求被合并次數

r/s: 每秒完成的讀次數

w/s: 每秒完成的寫次數

rkB/s: 每秒讀資料量(kB為機關)

wkB/s: 每秒寫資料量(kB為機關)

avgrq-sz:平均每次IO操作的資料量(扇區數為機關)

avgqu-sz: 平均等待處理的IO請求隊列長度

await: 平均每次IO請求等待時間(包括等待時間和處理時間，毫秒為機關)

svctm: 平均每次IO請求的處理時間(毫秒為機關) （該參數已經廢止，不可信）

%util: 采用周期内用于IO操作的時間比率，即IO隊列非空的時間比率

對于以上示例輸出，我們可以擷取到以下資訊：

每秒向磁盤上寫30M左右資料(wkB/s值)

每秒有91次IO操作(r/s+w/s)，其中以寫操作為主體

平均每次IO請求等待處理的時間為120.57毫秒，處理耗時為6.33毫秒

等待處理的IO請求隊列中，平均有11.79個請求駐留

以上各值之間也存在聯系，我們可以由一些值計算出其他數值，例如：

util = (r/s+w/s) * (svctm/1000)

對于上面的例子有：util = (1+90)*(6.33/1000) = 0.57603

rrqm/s：每秒這個裝置相關的讀取請求有多少被Merge了（當系統調用需要讀取資料的時候，VFS将請求發到各個FS，如果FS發現不同的讀取請求讀取的是相同Block的資料，FS會将這個請求合并Merge）；

wrqm/s：每秒這個裝置相關的寫入請求有多少被Merge了。

r/s： 該裝置的每秒完成的讀請求數（merge合并之後的）

w/s:  該裝置的每秒完成的寫請求數（merge合并之後的）

rKB/s：每秒發送給該裝置的總讀請求數 #rMB/s

wKB/s：每秒發送給該裝置的總寫請求數 #wMB/s

avgrq-sz 平均請求扇區的大小

avgqu-sz 是平均請求隊列的長度。毫無疑問，隊列長度越短越好。  

await:每一個IO請求的處理的平均時間（機關是微秒毫秒）。這裡可以了解為IO的響應時間，一般地系統IO響應時間應該低于5ms，如果大于10ms就比較大了。

這個時間包括了隊列時間和服務時間，也就是說，一般情況下，await大于svctm，它們的內插補點越小，則說明隊列時間越短，反之內插補點越大，隊列時間越長，說明系統出了問題。

r_await:讀IO的響應時間

w_await:寫IO的響應時間

（該參數已經廢止，不可信）svctm: 表示平均每次裝置I/O操作的服務時間（以毫秒為機關）。如果svctm的值與await很接近，表示幾乎沒有I/O等待，磁盤性能很好，如果await的值遠高于svctm的值，

則表示I/O隊列等待太長，系統上運作的應用程式将變慢。

​​Is the svctm's output of iostat unreliable as described within the man page? - Red Hat Customer Portal​​

%util： 在統計時間内所有處理IO時間，除以總共統計時間。例如，如果統計間隔1秒，該裝置有0.8秒在處理IO，而0.2秒閑置，那麼該裝置的%util = 0.8/1 = 80%，是以該參數暗示了裝置的繁忙程度。

一般地，如果該參數是100%表示裝置已經接近滿負荷運作了（當然如果是多磁盤，即使%util是100%，因為磁盤的并發能力，是以磁盤使用未必就到了瓶頸）。

rsec/s：每秒讀取的扇區數；

wsec/：每秒寫入的扇區數。

avg-cpu 部分輸出項說明：%user在使用者級别運作所使用的 CPU 的百分比。%nicenice 操作所使用的 CPU 的百分比。%system在核心級别（kernel）運作所使用 CPU 的百分比。%iowaitCPU 等待硬體 I/O 所占用 CPU 的百分比。%steal當管理程式（hypervisor）為另一個虛拟程序提供服務而等待虛拟 CPU 的百分比。%idleCPU 空閑時間的百分比。Device 部分基本輸出項說明：tps每秒鐘實體裝置的 I/O 傳輸總量。Blk_read讀入的資料總量，機關為塊。Blk_wrtn寫入的資料總量，機關為塊。kB_read讀入的資料總量，機關為KB。kB_wrtn寫入的資料總量，機關為KB。MB_read讀入的資料總量，機關為MB。MB_wrtn寫入的資料總量，機關為MB。Blk_read/s每秒從驅動器讀入的資料量，機關為 塊/s。Blk_wrtn/s每秒向驅動器寫入的資料量，機關為 塊/s。kB_read/s每秒從驅動器讀入的資料量，機關為KB/s。kB_wrtn/s每秒向驅動器寫入的資料量，機關為KB/s。MB_read/s每秒從驅動器讀入的資料量，機關為MB/s。MB_wrtn/s每秒向驅動器寫入的資料量，機關為MB/s。Device 部分擴充輸出項說明：rrqm/s将讀入請求合并後，每秒發送到裝置的讀入請求數。wrqm/s将寫入請求合并後，每秒發送到裝置的寫入請求數。r/s每秒發送到裝置的讀入請求數。w/s每秒發送到裝置的寫入請求數。rsec/s每秒從裝置讀入的扇區數。wsec/s每秒向裝置寫入的扇區數。rkB/s每秒從裝置讀入的資料量，機關為 KB/s。wkB/s每秒向裝置寫入的資料量，機關為 KB/s。rMB/s每秒從裝置讀入的資料量，機關為 MB/s。wMB/s每秒向裝置寫入的資料量，機關為 MB/s。avgrq-sz發送到裝置的請求的平均大小，機關為扇區。avgqu-sz發送到裝置的請求的平均隊列長度。awaitI/O請求平均執行時間。包括發送請求和執行的時間。機關為毫秒。svctm發送到裝置的I/O請求的平均執行時間。機關為毫秒。 （該參數已經廢止，不可信）%util在I/O請求發送到裝置期間，占用CPU時間的百分比。用于顯示裝置的帶寬使用率。當這個值接近100%時，表示裝置帶寬已經占滿。 iostat 中的 %util 名額說明

判斷磁盤極限性能誤區：隻通過iostat 中的 %util 名額确定磁盤是否達到帶寬或iops極限

背景：

    在判斷磁盤是否達到極限性能時，總有人通過 iostat -x 中的 %util 名額來确認磁盤是否帶寬帶寬或IOPS瓶頸，其實這是不對的，特做如下說明：

結論：

    iostat 中的 %util 基本已經沒有任何作用了，svctm也沒什麼參考意義

    磁盤是否達到真正極限瓶頸，需要參考通過fio等工具壓測出的極限帶寬和IOPS值

%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)有沒有哪個名額可以衡量硬碟裝置的飽和程度呢？很遺憾，沒有。