容易被誤讀的IOSTAT

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

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

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

(rd_ios)讀操作的次數。

(rd_merges)合并讀操作的次數。如果兩個讀操作讀取相鄰的數據塊時,可以被合并成一個,以提高效率。合并的操作通常是I/O scheduler(也叫elevator)負責的。

(rd_sectors)讀取的扇區數量。

(rd_ticks)讀操作消耗的時間(以毫秒為單位)。每個讀操作從__make_request()開始計時,到end_that_request_last()為止,包括了在隊列中等待的時間。

(wr_ios)寫操作的次數。

(wr_merges)合并寫操作的次數。

(wr_sectors)寫入的扇區數量。

(wr_ticks)寫操作消耗的時間(以毫秒為單位)。

(in_flight)當前未完成的I/O數量。在I/O請求進入隊列時該值加1,在I/O結束時該值減1。

注意:是I/O請求進入隊列時,而不是提交給硬盤設備時。

(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停止計時。

(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

2Device:rrqm/swrqm/sr/sw/srsec/swsec/savgrq-szavgqu-szawaitsvctm%util

sdg0.000.00133.000.002128.000.0016.001.007.507.4999.60

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

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容

  • 這篇文章主要介紹一些常用的linux服務器性能監控命令,包括命令的常用參數、指標的含義以及一些交互操作。 幾個問題...
    dancingking閱讀 8,393評論 6 22
  • 在聽“”王子“”分享的過程中剛好聽到他曾做過性能方面的測試,事后向他請教,他把他在簡書寫的Linux服務器監控命...
    許小小晴閱讀 739評論 0 0
  • 記一次非凡的理發體驗 下午,16點35分,我抱著剛借來的四本書從社科館出來,素黑的兩本愛自己,還有一本廣告書以及P...
    十三爺閱讀 820評論 0 1
  • 鄧紫棋就是出了名的大象腿,也是肌肉型腿,其實她是肌肉和脂肪的混合,很多人也是這樣,我覺得 水腫型腿,脂肪型腿,...
    汪2爺DoubleW閱讀 966評論 10 27
  • 經典手勢,勾起了我童年的回憶 妹子,踏浪而來 又是豬一樣的隊友 別看你們人多,我也不怕 繩子好長啊,怎么也拉不到頭...
    搞笑精選app閱讀 620評論 0 0