最近又接到一個關於磁碟的問題，所以，把磁碟性能的分析過程整理了一遍。上一篇主要體現分析思路。這一篇介紹一下要用到的工具。

性能指標

IOPS：Input/Output Per Second， 即每秒系統能能處理的I/O請求數量。

TPUT: 吞吐量。

不同的應用場境，對上述兩個指標的關注度是不同的。

隨機讀寫頻繁的應用，如小文件存儲(圖片)、資料庫，關注隨機讀寫性能，IOPS是關鍵衡量指標。

順序讀寫頻繁的應用，如電視臺的視頻編輯，備份系統，關注連續讀寫性能。數據吞吐量是關鍵衡量指標。

由於傳統的機械硬碟是旋轉圓盤，因此，讀寫需要操作磁頭到達目標磁軌和定位扇區。這意味著機械硬碟還有兩個物理指標：尋道時間 和 旋轉延遲 。

常見磁碟平均物理尋道時間為：

  • 7200 轉/分的STAT硬碟平均物理尋道時間是9ms，平均旋轉延遲大約 4.17ms
  • 10000轉/分的STAT硬碟平均物理尋道時間是6ms ，平均旋轉延遲大約 3ms
  • 15000轉/分的SAS硬碟平均物理尋道時間是4ms，平均旋轉延遲大約 2ms

最大IOPS的理論計算方法 ： IOPS = 1000 ms/ (尋道時間 + 旋轉延遲)。忽略數據傳輸時間。

  • 7200 rpm的磁碟IOPS = 1000 / (9 + 4.17) = 76 IOPS
  • 10000 rpm的磁碟IOPS = 1000 / (6+ 3) = 111 IOPS
  • 15000 rpm的磁碟IOPS = 1000 / (4 + 2) = 166 IOPS

RAID0/RAID5/RAID6的多塊磁碟可以並行工作，所以，在這樣的硬體條件下， IOPS 相應倍增。假如， 兩塊15000 rpm 磁碟的話，166 * 2 = 332 IOPS。

上述通過基本原理計算出的 IOPS 是物理設備的下限。 實際運行環境中，隨著讀寫請求的發生位置，隊列深度，調度演算法的不同，測試出的 IOPS 會更高。

維基上列出了常見硬碟的IOPS （en.wikipedia.org/wiki/I），我摘錄一些：

SSD達到了驚人的100,000。 見下圖

還有一些其它的指標： IO latency 等。

標定

與 CPU 不同，不同環境下，磁碟的性能指標與廠家標稱會不一致。因此，在性能分析前，對所在的計算環境進行標定是很有必要的。用於標定的工具是 fio 。

wget ftp.tu-chemnitz.de/pub/

fio -filename=/dev/sda -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=100 -group_reporting -name=mytest -ioscheduler=noop

上述命令，進行隨機讀寫測試。隊列深度為1。

VM (long time running) 是 測試用的虛擬機。這臺 VM的磁碟性能極低。只有兩位數。同一臺 ESXi 上的另一臺 VM（new build )，磁碟性能很正常。兩者的區別在於，前者不是新裝，而是一直跑 volume test 。後者是新安裝的。

分析工具

  • iostat -x 10

最常用的是 iostat 。10 是時間週期，每10秒輸出一份統計數據。

在這個統計數據中，被紅框標出的是需要關注的數據。

wrqm/s 是 每秒中 merge 的寫請求的數量。 一些寫請求可以合併成一個寫請求發給驅動。上圖中，這個數值很小，說明在這10秒裏主要是隨機寫。

r/s / w/s 是 IO 請求數量，也就是 IOPS， 減去 rqm 就是實際到達驅動的 IOPS 。在這臺機器上，IOPS 穩定在250左右時， %util 達到 99.75%

%util 表示的是 佔用率。它的計算是 Δio_ticks /Δt . 分子是單位時間內 IO 操作佔用的時間，分母是單位時間。有可能 IO 操作少，但總的佔用時間長，佔用率也可以很高。也可能 IO 操作很多，但大部分都 merge 也，而且 總的佔用時間少，那麼　佔用率就低。

await 是 IO 請求排隊的時間 ，它基本等於 Q2D （這個指標見下文）。 時間越長，意味著延時越長。也就是 IO latency 指標。

這個工具給出的數據不能孤立的看。需要組合在一起來分析。當我們想了解為什麼 await 為什麼那麼長時，就需要使用下面的工具。

  • blktrace

這個命令很強大，不僅僅可以用來分析 DISK IO。我們在這裡只用它的 DISK IO 分析能力。

cd /var/VM_ramdisk 首先，進入 RAM 盤，以免記錄數據時，對磁碟產生壓力，幹擾測試結果。

blktrace -d /dev/sda 記錄磁碟 /dev/sda 讀寫執行的數據。按 Ctrl-C 中止，這時，目錄下會產生很多文件。文件名為 sda.blktrace.0。一個 CPU 一個文件。

blkparse -i sda -d sda.blktrace.bin 將所有的文件合併為一個binary dump 文件。

btt -i sda.blktrace.bin | more 最後，可以打開這個 dump 文件，查看分析結果。

Q2G → G2I → I2D → D2C 是 IO請求從應用發出，至到達磁碟的全過程。每個階段代表的是：

Q – 即將生成IO請求

|G – IO請求生成|I – IO請求進入IO Scheduler隊列|D – IO請求進入driver

|

C – IO請求執行完畢

上面的 AVG 列，顯示了每個過程平均花費時間。上面的數據一共記錄了 209579 個請求。 Q2C 的平均時間為 36.17ms。

G2I 平均花費了整個週期的 10.21%， I2D 平均花費了整個週期的13.80%， D2C 平均花費了整個週期的 71.92%。

比較好的運行狀態是，Q2G, G2I, I2D 都應該只佔有很小很小的百分比。而 D2C 佔有超過90%。上圖表明，當前的IO運行情況不佳。另一個數據 MAX ，也表明，IO 執行的很不平穩，最大值達到 9.04 秒，抖動非常厲害。

  • iowatcher

僅僅查看數據進行分析，非常的不直觀。工具 iowatcher 可以把 blktrace 採集的信息，轉化為圖像和動畫，方便分析。

  • iowatcher -t sda.blktrace.bin -o disk.svg
  • iowatcher -t sda.blktrace.bin --movie -o disk.mp4

首先，我們看 VM volume test 的圖像和動畫：

視頻封面

00:37

解讀： 從 Device IO 圖可以看到，讀寫是相當分散的，說明這時，VM 產生的主要是隨機讀寫。從吞吐量來看，讀寫都不高。這也符合隨機讀寫的場境。IOPs 穩定在 290左右。

下面，對比R440 物理機在日常運行時的圖像和動畫：

視頻封面

00:37

解讀：從 DISK IO圖來看，讀的量不大，而且寫主要是連續寫。其它的指標也都顯著好於 VM。

附上DELL R440 的 btt 數據：

推薦閱讀：

相關文章