【測試】linux FIO命令詳解(一)：磁碟IO測試工具 fio (並簡要介紹iostat工具)
目錄
原文：https://blog.csdn.net/don_chiang709/article/details/92628623
FIO介紹
FIO是測試IOPS的非常好的工具，用來對磁碟進行壓力測試和驗證。磁碟IO是檢查磁碟效能的重要指標，可以按照負載情況分成照順序讀寫，隨機讀寫兩大類。
FIO是一個可以產生很多執行緒或程序並執行使用者指定的特定型別I/O操作的工具，IO 是一個多執行緒io生成工具，可以生成多種IO模式，用來測試磁碟裝置的效能（也包含檔案系統：如針對網路檔案系統 NFS 的IO測試）。
fio在github上的座標：https://github.com/axboe/fio。
檢視當前 fio 已支援的 IO 引擎
# fio --enghelp
Available IO engines:
cpuio
mmap
sync
psync
vsync
pvsync
null
net
netsplice
libaio
rdma
posixaio
falloc
e4defrag
splice
rbd
mtd
sg
binjectFIO 工具常用引數：
引數說明：
filename=/dev/sdb1 測試檔名稱，通常選擇需要測試的盤的data目錄。
direct=1
rw=randwrite 測試隨機寫的I/O
rw=randrw 測試隨機寫和讀的I/O
bs=16k 單次io的塊檔案大小為16k
bsrange=512-2048 同上，提定資料塊的大小範圍
size=5G 每個執行緒讀寫的資料量是5GB。
numjobs=1 每個job（任務）開1個執行緒，這裡=幾個，後面每個用-name指定的任務就開幾個執行緒測試。所以最終執行緒數=任務數（幾個name=jobx）* numjobs。
thread 使用pthread_create建立執行緒，另一種是fork建立程序。程序的開銷比執行緒要大，一般都採用thread測試。
runtime=1000 測試時間為1000秒，如果不寫 則一直將5g檔案分4k每次寫完為止。
ioengine=libaio 指定io引擎使用libaio方式。libaio：Linux本地非同步I/O。請注意，Linux可能只支援具有非緩衝I/O的排隊行為（設定為“direct=1”或“buffered=0”）；rbd:通過librbd直接訪問CEPH Rados
iodepth=16 佇列的深度為16.在非同步模式下，CPU不能一直無限的發命令到SSD。比如SSD執行讀寫如果發生了卡頓，那有可能系統會一直不停的發命令，幾千個，甚至幾萬個，這樣一方面SSD扛不住，另一方面這麼多命令會很佔記憶體，系統也要掛掉了。這樣，就帶來一個引數叫做佇列深度。
Block Devices（RBD），無需使用核心RBD驅動程式（rbd.ko）。該引數包含很多ioengine，如：libhdfs/rdma等
rwmixwrite=30 在混合讀寫的模式下，寫佔30%
group_reporting 關於顯示結果的，彙總每個程序的資訊。
此外
lockmem=1g 只使用1g記憶體進行測試。
zero_buffers 用0初始化系統buffer。
nrfiles=8 每個程序生成檔案的數量。
磁碟讀寫常用測試點：
1. Read=100% Ramdon=100% rw=randread (100%隨機讀)
2. Read=100% Sequence=100% rw=read （100%順序讀）
3. Write=100% Sequence=100% rw=write （100%順序寫）
4. Write=100% Ramdon=100% rw=randwrite （100%隨機寫）
5. Read=70% Sequence=100% rw=rw, rwmixread=70, rwmixwrite=30
（70%順序讀，30%順序寫）
6. Read=70% Ramdon=100% rw=randrw, rwmixread=70, rwmixwrite=30
(70%隨機讀，30%隨機寫)
fio例子：
[[email protected] sda]# fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=read -filename=/dev/sda -name="BS 4KB read test" -iodepth=16 -runtime=60
BS 4KB read test: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
fio-3.7
Starting 1 thread
Jobs: 1 (f=1): [R(1)][100.0%][r=89.3MiB/s,w=0KiB/s][r=22.9k,w=0 IOPS][eta 00m:00s]
BS 4KB read test: (groupid=0, jobs=1): err= 0: pid=18557: Thu Apr 11 13:08:11 2019
read: IOPS=22.7k, BW=88.5MiB/s (92.8MB/s)(5313MiB/60001msec)
slat (nsec): min=901, max=168330, avg=6932.34, stdev=1348.82
clat (usec): min=90, max=63760, avg=698.08, stdev=240.83
lat (usec): min=97, max=63762, avg=705.17, stdev=240.81
clat percentiles (usec):
| 1.00th=[ 619], 5.00th=[ 627], 10.00th=[ 627], 20.00th=[ 635],
| 30.00th=[ 635], 40.00th=[ 685], 50.00th=[ 717], 60.00th=[ 725],
| 70.00th=[ 725], 80.00th=[ 725], 90.00th=[ 734], 95.00th=[ 816],
| 99.00th=[ 1004], 99.50th=[ 1020], 99.90th=[ 1057], 99.95th=[ 1057],
| 99.99th=[ 1860]
bw ( KiB/s): min=62144, max=91552, per=100.00%, avg=90669.02, stdev=3533.77, samples=120
iops : min=15536, max=22888, avg=22667.27, stdev=883.44, samples=120
lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=93.85%, 1000=5.14%
lat (msec) : 2=0.99%, 4=0.01%, 10=0.01%, 50=0.01%, 100=0.01%
cpu : usr=5.35%, sys=23.17%, ctx=1359692, majf=0, minf=17
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=1360097,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=16
Run status group 0 (all jobs):
READ: bw=88.5MiB/s (92.8MB/s), 88.5MiB/s-88.5MiB/s (92.8MB/s-92.8MB/s), io=5313MiB (5571MB), run=60001-60001msec
Disk stats (read/write):
sda: ios=1357472/0, merge=70/0, ticks=949141/0, in_queue=948776, util=99.88%
io=執行了多少M的IO
bw=平均IO頻寬
iops=IOPS
runt=執行緒執行時間
slat=提交延遲，提交該IO請求到kernel所花的時間（不包括kernel處理的時間）
clat=完成延遲,提交該IO請求到kernel後，處理所花的時間
lat=響應時間
cpu=利用率
IO depths=io佇列
IO submit=單個IO提交要提交的IO數
IO complete=Like the above submit number, but for completions instead.
IO issued=The number of read/write requests issued, and how many of them were short.
IO latencies=IO完延遲的分佈
io=總共執行了多少size的IO
aggrb=group總頻寬
minb=最小.平均頻寬.
maxb=最大平均頻寬.
mint=group中執行緒的最短執行時間.
maxt=group中執行緒的最長執行時間.
ios=所有group總共執行的IO數.
merge=總共發生的IO合併數.
ticks=Number of ticks we kept the disk busy.
io_queue=花費在佇列上的總共時間.
util=磁碟利用率
fio 有很多測試任務配置檔案，在git工程 examples 資料夾中，我們可以使用命令列引數進行直接配置，也可以直接通過配置檔案配置一次測試的內容。
更詳細對fio輸出說明請參考博文：Fio Output Explained
fio工作引數可以寫入配置檔案
http://xiaqunfeng.cc/2017/07/12/fio-test-ceph/
測試librbd
1、建立一個image
rbd -p rbd create --size 2048 fio_test
2、撰寫 job file：rbd.fio
######################################################################
# Example test for the RBD engine.
#
# Runs a 4k random write test agains a RBD via librbd
#
# NOTE: Make sure you have either a RBD named 'fio_test' or change
# the rbdname parameter.
######################################################################
[global]
#logging
#write_iops_log=write_iops_log
#write_bw_log=write_bw_log
#write_lat_log=write_lat_log
ioengine=rbd
clientname=admin
pool=rbd
rbdname=fio_test
invalidate=0 # mandatory
rw=randwrite
bs=4k
[rbd_iodepth32]
iodepth=32以上 job file 將執行整個RBD大小的100％隨機寫入測試（將通過librbd確定），Ceph使用者admin使用Ceph 預設 poolrbd和剛剛建立的空的 RBD fio_test，寫的 blocksize 為 4k 和 iodepth 為32 。 引擎正在使用非同步IO。
當前實施限制：
- invalidate = 0 現在是強制需要的，engine 現在沒有這個會返回失敗。
- 測試完成後
rbd引擎不會被清除。完成測試執行後，給定的RBD將被填充。（我們現在使用它進行預填充測試，並在需要時重新建立RBD。）
部分參考：Ceph Performance Analysis: fio and RBD
3、測試
fio rbd.fio
IO狀態監控：
進行磁碟測試的時候，我們可以使用iostat 等監控工具，檢視所有磁碟當前的讀寫狀態（fedora 系統上sysstat-11.7.3-2.fc29.x86_64 收錄了此工具）。
監控磁碟IO命令：iostat –mx 1
Iostat介紹
iostat主要用於監控系統裝置的IO負載情況，iostat首次執行時顯示自系統啟動開始的各項統計資訊，之後執行iostat將顯示自上次執行該命令以後的統計資訊。使用者可以通過指定統計的次數和時間來獲得所需的統計資訊。
語法
iostat [ -c ] [ -d ] [ -h ] [ -N ] [ -k | -m ] [ -t ] [ -V ] [ -x ] [ -z ] [ device [...] | ALL ] [ -p [ device [,...] | ALL ] ] [ interval [ count ] ]
iostat使用範例：
iostat -d -x -k 1 10
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 1.56 28.31 7.80 31.49 42.51 2.92 21.26 1.46 1.16 0.03 0.79 2.62 10.28
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 2.00 20.00 381.00 7.00 12320.00 216.00 6160.00 108.00 32.31 1.75 4.50 2.17 84.20
-d: 顯示該裝置的狀態的引數；
-x：是一個比較常用的選項，該選項將用於顯示和io相關的擴充套件資料。
-k: 靜態顯示每秒的統計（單位kilobytes ）
1: 第一個數字表示每隔1秒重新整理一次資料顯示。
10：第二個數字表示總共的重新整理次數
輸出資訊的含義
rrqm/s：每秒這個裝置相關的讀取請求有多少被Merge了（當系統呼叫需要讀取資料的時候，VFS將請求發到各個FS，如果FS發現不同的讀取請求讀取的是相同Block的資料，FS會將這個請求合併Merge）；
wrqm/s：每秒這個裝置相關的寫入請求有多少被Merge了。
r/s： 該裝置的每秒完成的讀請求數（merge合併之後的）
w/s: 該裝置的每秒完成的寫請求數（merge合併之後的）
rsec/s：每秒讀取的扇區數；
wsec/：每秒寫入的扇區數。
rKB/s：每秒傳送給該裝置的總讀請求數
wKB/s：每秒傳送給該裝置的總寫請求數
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%，因為磁碟的併發能力，所以磁碟使用未必就到了瓶頸）。
參考：