[20171231]iostat -x命令診斷解析.txt
[20171231]iostat -x命令診斷解析.txt
--//使用iostat診斷IO問題,裡面的一些輸出含義經常忘記,做一個記錄:
輸出資訊的含義
rrqm/s:每秒這個裝置相關的讀取請求有多少被Merge了(當系統呼叫需要讀取資料的時候,VFS將請求發到各個FS,如果FS發現不同的讀
取請求讀取的是相同Block的資料,FS會將這個請求合併Merge);
wrqm/s:每秒這個裝置相關的寫入請求有多少被Merge了。
rsec/s:每秒讀取的扇區數;
wsec/ :每秒寫入的扇區數。
r/s : The number of read requests that were issued to the device per second.
w/s : The number of write requests that were issued to the device per second.
rkB/s : The number of kilobytes read from the device per second.
wkB/s : The number of kilobytes written to the device per second.
avgrq-sz 平均請求扇區的大小
avgqu-sz 是平均請求佇列的長度。毫無疑問,佇列長度越短越好。
await : 每一個IO請求的處理的平均時間(單位是微秒毫秒)。這裡可以理解為IO的響應時間,一般地系統IO響應時間應該低於5ms,如果
大於10ms就比較大了。
這個時間包括了佇列時間和服務時間,也就是說,一般情況下,await大於svctm,它們的差值越小,則說明佇列時間越短,反
之差值越大,佇列時間越長,說明系統出了問題。
svctm 表示平均每次裝置I/O操作的服務時間(以毫秒為單位)。如果svctm的值與await很接近,表示幾乎沒有I/O等待,磁碟效能很好
,如果await的值遠高於svctm的值,則表示I/O佇列等待太長,系統上執行的應用程式將變慢。
%util: 在統計時間內所有處理IO時間,除以總共統計時間。例如,如果統計間隔1秒,該裝置有0.8秒在處理IO,而0.2秒閒置,那麼該
%裝置的%util = 0.8/1 = 80%,所以該引數暗示了裝置的繁忙程度
一般地,如果該引數是100%表示裝置已經接近滿負荷執行了(當然如果是多磁碟,即使%util是100%,因為磁碟的併發能力,所以磁碟使用
未必就到了瓶頸)。
--//例子:
# iostat -d -x -k 1 10 | grep sda3
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda3 0.06 8.25 0.37 3.78 21.51 48.13 33.54 0.07 17.24 11.72 4.86
sda3 0.00 9.90 0.00 5.94 0.00 63.37 21.33 0.08 13.33 13.33 7.92
sda3 0.00 6.00 0.00 3.00 0.00 36.00 24.00 0.04 12.33 12.33 3.70
sda3 0.00 30.00 0.00 25.00 0.00 220.00 17.60 0.23 9.36 9.36 23.40
sda3 0.00 6.00 0.00 5.00 0.00 44.00 17.60 0.08 15.20 15.20 7.60
sda3 0.00 6.00 0.00 4.00 0.00 40.00 20.00 0.05 11.75 11.75 4.70
sda3 0.00 38.00 0.00 14.00 0.00 208.00 29.71 0.13 9.50 9.50 13.30
sda3 0.00 7.00 41.00 7.00 336.00 56.00 16.33 0.27 5.56 5.00 24.00
sda3 0.00 9.00 134.00 5.00 1080.00 44.00 16.17 1.67 5.27 4.31 59.90
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sda3 0.00 19.00 69.00 37.00 552.00 236.00 14.87 1.82 26.03 4.04 42.80
--//注:應該沒有Device這行輸出,我補上為了檢視方便.
--//%util的計算:
%util =( r/s + w/s ) * svctm /1000 * 100
(134.00+5.00)*4.31/1000*100 = 59.909
(41.00+7.00)*5.00/1000*100 = 24.0000
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/267265/viewspace-2149582/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Linux iostat 命令LinuxiOS
- Mac OSX網路診斷命令Mac
- linux每日命令(38):iostat命令LinuxiOS
- Linux iostat命令基本使用LinuxiOS
- oracle RAC 診斷叢集狀態命令Oracle
- 幾個常用的網路診斷命令
- 使用MTR命令診斷網路問題
- UDS診斷之0x11服務
- 容器內的Linux診斷工具0x.toolsLinux
- [20180312]iostat顯示輸出問題.txtiOS
- [20180628]顯示bbed x命令格式.txt
- Linux學習之iostat命令詳解LinuxiOS
- [20210410]關於time命令的解析.txt
- 用更雲原生的方式做診斷|大規模 K8s 叢集診斷利器深度解析K8S
- [JVM] 應用診斷工具之Fastthread(線上診斷)JVMASTthread
- IO實時監控命令iostat詳解iOS
- ORACLE診斷案例Oracle
- Linux儲存效能觀測——iostat命令詳解LinuxiOS
- Java診斷利器ArthasJava
- SQL問題診斷SQL
- Linux基礎命令---iostat顯示裝置狀態LinuxiOS
- 影像分類學習:X光胸片診斷識別----遷移學習遷移學習
- 免費網站seo診斷:從哪些維度進行診斷呢?網站
- iostat用法iOS
- Java執行緒診斷Java執行緒
- Oracle診斷事件列表(轉)Oracle事件
- 熔斷器 Hystrix 原始碼解析 —— 執行命令方式原始碼
- AI診斷心臟病比人類更準?但這只是識圖,不是診斷AI
- openGauss 支援WDR診斷報告
- 故障分析 | Kubernetes 故障診斷流程
- 如何選擇java診斷工具Java
- .NET Core 服務診斷工具
- 整車EOL 診斷系統
- .Net Core服務診斷排查
- 9 Oracle Data Guard 故障診斷Oracle
- 整車EOL診斷系統
- Oracle診斷案例-Sql_traceOracleSQL
- 網路診斷工具的使用
- oracle之 redo過高診斷Oracle