關於IO性能的一些學習與瞭解
摘要
最近心氣不高.
學習進度也拖的比較慢.
以後想能夠多爲自己着想.自己有自己的節奏, 不能只爲別人考慮.
要改變一下自己的做事風格. 一些事情想幫則幫, 不想幫就當看不見.
互勉.
磁盤IO的指標
IOPS
RT
BW
部分監控指標的解釋
iowait
await
util%
iowait
Percentage of time that the CPU or CPUs were idle during
which the system had an outstanding disk I/O request.
其實 iowait計算的標準就是 CPU在idle時存在IO操作的比率
第一點必須是CPU屬於idle的
第二點是進行了io操作
需要說明一下.所有的監控指標都是基於採樣的.
所以如果CPU的壓力很大, 是不會有太多 iowait的.
如果是單線程專用的情況可能存在io不足導致CPU在等待的情況
但是大多數情況可能就是CPU比較閒,沒有太多工作要做.
await
每個I/O的平均耗時,
包括在內核 IO 隊列內的時間和在存儲設備上執行此 IO 的時間,
所以 await 高可能有兩個原因,
一是 IO 在 IO queue 裏耗時較長,
二個就是由於 IO 在存儲設備上執行的時間比較長,
而 IO 在 IO queue 裏耗時較長可能是由於程序一次併發了過多的 IO, 讓 IO 在 queue 排隊,
IO 在存儲設備上執行的時間比較長也有可能時 IO 本身就比較大,
例如在硬盤上寫 1KB 文件, 耗時一定是比 1MB的時間短的,
所以 await 高, 還要結合業務本身的特點判斷 await 高的原因
來源: https://blog.csdn.net/MrSate/article/details/105372924
util%
這個反映 IO queue, 中存在 IO 在採樣週期裏的佔比,
只要 IO queue 中存在 IO, 就會被計入到 %util 的時間內,
無論是 1 個 IO 或者 100 個IO, 並且也只計算 IO 存在於 queue 裏面的時間,
所以此時即使磁盤壓力較大, 但是 IO queue 中並沒有排隊的 IO 那麼 %util 也不會高(例如每次 IO size 都比較大),
或者有些程序進行順序 IO, 完成幾個再發下一個, 並且 IO size 並不大, 此時即使磁盤壓力較小 %util 也會比較高
一些自己的理解
IO性能雖然有三個比較大的指標, 吞吐量, 響應時間, 每秒IO次數
但是能夠進行磁盤優化的地方也很多
需要說明一下. 監控指標是基於很早的機械磁盤來的
但是現階段因爲raid卡以及固態磁盤的飛速發展, 現在再看着三個監控指標的意義其實已經脫離了實際情況.
磁盤是通過磁頭的尋道來進行IO塊的尋找和基於磁頭對盤面進行磁性讀取進行數據讀取.
早期的磁盤其實磁頭比較少, 但是隨着現在硬盤技術的發展, 磁頭的數量越來越多.
現階段的硬盤都是盤面旋轉, 磁頭在旋轉帶起來的氣流將磁頭升起來. 然後由步進電機進行尋址和讀取寫入.
所以理論上的最大尋址時間是 60/轉速(rpm), 比如 15000rpm的磁盤,平均尋址時間就是最時間的一半約爲 2ms的時間.
前期操作系統的一些調度算法主要是 電梯算法 也是爲了將就磁盤磁頭進行位置選擇來提高尋址和讀取的速度.
這裏就有了 IO隊列數量和IO隊列深度的兩個概念.
IO對列數量和深度
按照機械磁盤的理解.
IO隊列可以理解爲 磁頭的數量.
隊列深度可以理解爲 操作系統一次給這個磁頭想要讀取和寫入的任務數量.
基於機械磁盤的一些設置在raid卡的大容量緩存,以及固態硬盤面前變的越來越難以發揮他的性能.
最開始的ACHI 其實只允許一個隊列, 並且隊列深度是32最大.
但是NVME的存儲協議下, 可以有 64000個對列, 並且每個隊列都可以有64000的深度.
如果隊列深度不夠, 就算是磁盤的性能足夠好, 也會導致磁盤喂不飽. 顯得性能比較弱一些.
關於USE, 利用率 錯誤率 飽和度
操作系統最容易觀測的是自己的行爲, 所以很多監控其實更多的考慮的是操作系統層的
到底硬件層的監控其實不是非常多.
比如
%util
表示採樣期間, 隊列裏面有沒有IO的請求, 其實並沒有考慮多少個隊列.
如果可以支持較多的隊列,但是僅用了一個隊列, 導致利用率很高, 但是實際上磁盤的豔麗並不是很大.
如果提高IO對列數量, 加深隊列深度, 還是能夠提高性能的
相反, 如果磁盤有壓力, 就不能提高太多, 這一塊可以通過RT時間來排查,
如果使用率很高, 但是RT時間很短,可以適當加大, 如果RT時間很長, 則需要考慮升級存儲.
%iowait
壽命採樣期間, CPU沒有壓力,或者是在等磁盤的返回
這個時候可以採用比如epoll 後者是其他的IO非阻塞模型來提高吞吐量
也可以使用異步模式來提高產品的性能. 當然, 如果此時IOPS和吞吐量都已經到達協議的上限
說明機器磁盤的確存在並且, 需要升級.
await
如果await時間較長, 說明要麼硬盤不夠快, 要麼隊列不合理, 需要進行調整
調整也是需要根據 磁盤的吞吐量, IOPS, 以及RT來記性
如果吞吐量低, 速度快, 可能跟隊列數量有關係, 或者是調度算法有關, 需要進行處理.
總結
任何事物都要從多個角度來進行查看
不能就一個指標就得出結論
需要辯證的完整的去查看系統性能.
共勉.
