中文字幕av专区_日韩电影在线播放_精品国产精品久久一区免费式_av在线免费观看网站

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

Linux主機監控命令-iostat

發布時間:2020-06-22 17:08:04 來源:網絡 閱讀:445 作者:lifayi2008 欄目:移動開發

IOSTAT CUP平均負載,硬盤活動

 

#iostat -d -k -t 2

第一次輸出的磁盤IO負載狀況提供了關于自從系統啟動以來的統計信息。隨后的每一次輸出則是每個間隔之間的平均IO負載狀況。

iostat -d -k –t 1 10

Device:  tps  kB_read/s  kB_wrtn/s  kB_read      kB_wrtn
sda     14.54  417.21   368.06    15719357562  13867444535
dm-0   104.60  415.64   366.87    15660312829  13822621684
dm-1    0.69   1.57       1.19     59041280     44822840

-d:顯示某塊具體硬盤,這里沒有給出硬盤路徑就是默認全部了

-k:以KB為單位顯示 1:統計間隔為1  10:共統計10次的  -t 要求打印出時間信息

tps:該設備每秒的傳輸次數(Indicate the number of transfers per second that were issued to the device.)。一次傳輸意思是一次I/O請求。多個邏輯請求可能會被合并為一次I/O請求一次傳輸請求的大小是未知的。

kB_read/s:每秒從設備(drive expressed)讀取的數據量;kB_wrtn/s:每秒向設備(drive expressed)寫入的數據量;kB_read:讀取的總數據量;kB_wrtn:寫入 的總數量數據量;這些單位都為Kilobytes

一開始的數值很大是因為顯示的是累計讀寫量

 

# iostat -x 1 10

Linux 2.6.18-92.el5xen 02/03/2009

avg-cpu:   %user %nice %system %iowait   %steal  %idle

            1.10   0.00   4.82    39.54      0.07   54.46

Device:   rrqm/s wrqm/s  r/s   w/s  rsec/s wsec/s avgrq-sz avgqu-sz await   svctm  %util

sda       0.00    3.50   0.40  2.50  5.60  48.00   18.48   0.00     0.97    0.97     0.28

sdb       0.00    0.00   0.00  0.00  0.00  0.00    0.00    0.00     0.00     0.00    0.00

sdc       0.00    0.00   0.00  0.00  0.00   0.00   0.00    0.00      0.00    0.00     0.00

sdd       0.00    0.00   0.00  0.00  0.00   0.00   0.00    0.00      0.00    0.00     0.00

sde       0.00    0.10   0.30  0.20  2.40   2.40   9.60    0.00      1.60    1.60     0.08

sdf        17.40   0.50  102.00 0.20  12095.2 5.60 118.40   0.70      6.81    2.09   21.36

sdg       232.40 1.90 379.70   0.50 76451.20 19.20 201.13     4.94 13.78 2.45   93.16

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壓力高)

另外還可以參考

一般:

svctm < await (因為同時等待的請求的等待時間被重復計算了)

svctm的大小一般和磁盤性能有關:CPU/內存的負荷也會對其有影響,請求過多也會間接導致 svctm 的增加。

await: await的大小一般取決于服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。

如果 svctm 比較接近 await,說明I/O 幾乎沒有等待時間;

如果 await 遠大于 svctm,說明 I/O隊列太長,應用得到的響應時間變慢,

如果響應時間超過了用戶可以容許的范圍,這時可以考慮更換更快的磁盤,調整內核 elevator算法,優化應用,或者升級 CPU

隊列長度(avgqu-sz)也可作為衡量系統 I/O 負荷的指標,但由于 avgqu-sz 是按照單位時間的平均值,所以不能反映瞬間的 I/O 洪水。

 

   別人一個不錯的例子.(I/O 系統 vs. 超市排隊)

舉一個例子,我們在超市排隊 checkout 時,怎么決定該去哪個交款臺呢? 首當是看排的隊人數,5個人總比20人要快吧?除了數人頭,我們也常常看看前面人購買的東西多少,如果前面有個采購了一星期食品的大媽,那么可以考慮換個隊排了。還有就是收銀員的速度了,如果碰上了連錢都點不清楚的新手,那就有的等了。另外,時機也很重要,可能 5分鐘前還人滿為患的收款臺,現在已是人去樓空,這時候交款可是很爽啊,當然,前提是那過去的 5 分鐘里所做的事情比排隊要有意義(不過我還沒發現什么事情比排隊還無聊的)

I/O 系統也和超市排隊有很多類似之處:

r/s+w/s 類似于交款人的總數

平均隊列長度(avgqu-sz)類似于單位時間里平均排隊人的個數

平均服務時間(svctm)類似于收銀員的收款速度

平均等待時間(await)類似于平均每人的等待時間

平均I/O數據(avgrq-sz)類似于平均每人所買的東西多少

I/O 操作率 (%util)類似于收款臺前有人排隊的時間比例。

我們可以根據這些數據分析出 I/O 請求的模式,以及 I/O 的速度和響應時間。

下面是別人寫的這個參數輸出的分析

# iostat -x 1

avg-cpu:   %user %nice %sys %idle

16.24 0.00 4.31 79.44

Device: rrqm/s wrqm/s r/s w/s   rsec/s   wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await   svctm   %util

/dev/cciss/c0d0

0.00   44.90   1.02 27.55 8.16   579.59     4.08 289.80 20.57 22.35 78.21 5.00   14.29

/dev/cciss/c0d0p1

0.00   44.90   1.02 27.55 8.16   579.59     4.08 289.80 20.57 22.35 78.21 5.00   14.29

/dev/cciss/c0d0p2

0.00 0.00   0.00   0.00 0.00 0.00     0.00     0.00     0.00     0.00 0.00 0.00 0.00

上面的 iostat 輸出表明秒有 28.57 次設備 I/O 操作: IO(io)/s = r/s() +w/s() = 1.02+27.55 = 28.57 (/) 其中寫操作占了主體 (w:r = 27:1)

平均每次設備 I/O 操作只需要 5ms 就可以完成,但每個 I/O 請求卻需要等上 78ms,為什么? 因為發出的 I/O 請求太多 (每秒鐘約 29 ),假設這些請求是同時發出的,那么平均等待時間可以這樣計算:

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

應用到上面的例子: 平均等待時間 = 5ms * (1+2+...+28)/29 = 70ms,和 iostat 給出的78ms 的平均等待時間很接近。這反過來表明 I/O 是同時發起的。

每秒發出的 I/O 請求很多 ( 29 ),平均隊列卻不長 (只有 2 個左右),這表明這 29 個請求的到來并不均勻,大部分時間 I/O 是空閑的。

一秒中有 14.29% 的時間 I/O 隊列中是有請求的,也就是說,85.71% 的時間里 I/O 系統無事可做,所有 29 I/O 請求都在142毫秒之內處理掉了。

delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s=78.21 * delta(io)/s = 78.21*28.57 =2232.8,表明每秒內的I/O請求總共需要等待2232.8ms。所以平均隊列長度應為 2232.8ms/1000ms = 2.23,而iostat 給出的平均隊列長度 (avgqu-sz) 卻為 22.35,為什么?! 因為 iostat 中有 bugavgqu-sz值應為 2.23,而不是 22.35

 

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

邓州市| 新蔡县| 大安市| 湖北省| 益阳市| 仁布县| 海门市| 饶平县| 衡阳市| 德兴市| 福安市| 汾阳市| 乃东县| 绥化市| 八宿县| 阳高县| 鹿邑县| 汉源县| 太原市| 井冈山市| 始兴县| 武胜县| 定结县| 昌黎县| 上杭县| 来宾市| 彭山县| 苍溪县| 临武县| 金坛市| 图片| 仁布县| 江口县| 安顺市| 全南县| 营口市| 三江| 驻马店市| 公主岭市| 丹巴县| 津南区|