天天看點

系統IO優化相關思路

 系統IO優化相關思路

-----------------------

最近原搭建的vcloud+vsphere5.1+openfiler的測試環境出現I/O瓶頸。

具體環境如下:

hostX4---單通道8GHBAX4------<FC鍊路>-------雙通道8GHBAX2----openfilerX1  

VM數量 60台

在openfiler端使用vmstat指令檢視

系統IO優化相關思路

在host段利用iostat工具檢視

系統IO優化相關思路

#iostat,這個需要先安裝sysstat ,即yum -y install sysstat 

系統IO優化相關思路

 ----------------------相關數值說明

I/O 操作: 總IO(io)/s = r/s(讀) +w/s(寫)

平均等待時間 = 單個I/O 服務時間 * ( 1 + 2 + ... + 請求總數-1) / 請求總數

rrqm/s: 每秒進行 merge 的讀操作數目。即 delta(rmerge)/s

wrqm/s:    每秒進行 merge 的寫操作數目。即 delta(wmerge)/s

r/s:           每秒完成的讀 I/O 裝置次數。即 delta(rio)/s

w/s:       每秒完成的寫 I/O 裝置次數。即 delta(wio)/s

rsec/s: 每秒讀扇區數。即 delta(rsect)/s

wsec/s:   每秒寫扇區數。即 delta(wsect)/s

rkB/s:   每秒讀K位元組數。是 rsect/s 的一半,因為每扇區大小為512位元組。(需要計算)

wkB/s: 每秒寫K位元組數。是 wsect/s 的一半。(需要計算)

avgrq-sz: 平均每次裝置I/O操作的資料 大小 (扇區)。delta(rsect+wsect)/delta(rio+wio)

avgqu-sz: 平均I/O隊列長度。即 delta(aveq)/s/1000 (因為aveq的機關為毫秒)。

await: 平均每次裝置I/O操作的等待時間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)

svctm: 平均每次裝置I/O操作的服務 時間 (毫秒)。即 delta(use)/delta(rio+wio)

%util:    一秒中有百分之多少的時間用于 I/O 操作,或者說一秒中有多少時間 I/O 隊列是非空的。即 delta(use)/s/1000 (因為use的機關為毫秒)

如果%util 接近100%,說明産生的I/O請求太多,I/O系統 已經滿負荷,該磁盤

可能存在瓶頸;idle 小于70% IO壓力就較大了,一般讀取速度有較多的wait。 

同時可以結合vmstat 檢視檢視b參數 (等待資源的程序數 )和wa參數(IO等待所占用的CPU時間的百分比,高過30%時IO壓力高 ) 

-----------------------------

結合其他工具分析,問題出在openfiler的IO處理性能上,磁盤事件等待時間遠大于磁盤處理時間。openfiler是用DELLR510搭建的用的SATA2TB做的raid5,本身磁盤性能較低,在多台host上多台vm同時讀取資料時候會出現處理排隊過長。。。。這個時候測試硬碟速度是正常的

後續因為測試環境不能申請進階儲存設備,決定拆掉1拖4的存儲布局,改成利用多台openfiler組ipsan線路做分散式存儲配合vm的磁盤DRS