fioを使用してIO性能テストを行う

ネット上でfioについての绍介はすでに多すぎて、使う时すべて直接持ってきて走って、私达は通常fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=write -size=10G -filename=test -name="Max throughput" -iodepth=4 -runtime=60これらを使ってテストして、しかし最近いくつかのユーザーの侧で、fioテストを使うことを発见して、ユーザーの皿はとても良くて、数百MBのスループットに达することができて、しかし私达はやっと100 MBまで走って、iostatの中のIO Utilは100%になりました.IO Util 100%が皿を食べて死んだわけではないことは分かっていますが、もう一つの面から、私たちはもっと多次元的にディスクの性能テストを行うべきだということに気づき、fioを振り返りました.

パラメータ

Fioの使用は本当に簡単で、主にいくつかの重要なパラメータカテゴリに注目すればいいです.
まずI/O engineです.これはfioがどのような方法でI/Oをテストするかを教えます.ビジネスの実際の状況に応じて異なるタイプを選択する必要があります.主にいくつかあります.

libaio-Linuxオリジナルの非同期I/O、これも通常こちらで使用する最も多くのテストディスクのスループットと遅延の方法

です.

sync-すなわち最も一般的なread/write動作

vsync-readv/writevを使用し、主に隣接するI/Oを

にマージします.

psync-対応pread/pwrite

pvsync/pvsync 2-対応するpreadv/pwritev、およびpreadv 2/p writev 2

他にももちろんいろいろありますが、実際にはこちらでは使っていませんので、後で使うかもしれません.RocksDBを使用しているので、ディスクへのアプリケーションの影響をよりよくテストするためにsync、vsyncのengineを使用して操作する必要があります.
I/O type、例えばdirectを使用するかbufferedを使用するか、bufferedの場合、I/Oの後にfsyncまたはfdatasyncを使用してsync操作を強制することに注意してください.テストのために適切なI/O patternを選択する必要があります.これは主にreadwriteで決定されます.

read-シーケンス読み

write-順序書き

trim-順次裁断

randread-ランダムリード

randwrite-ランダム書き込み

randtrim-ランダムトリミング

rw,readwrite-ハイブリッドシーケンス読み書き

randrw-ハイブリッドランダム読み書き

trimwrite-シーケンスの切り取り+シーケンス書き

ハイブリッドモードを使用すると、読み書きの割合を設定することもできます.通常は読み書きが半分ずつですが、実際には多くのシーンが読み書きが少ないはずです.rwmixread=90を使用して90%の読み書きを設定することができます.10%の書き込みを設定することもできます.rwmixwrite=90で設定することもできます.この2つのパラメータは実際には少し衝突しています.100未満であれば、fioは後ろの1つを使用します.
ランダム読み書きにとってもう一つの考慮すべき指標は操作分布でありrandom_を用いるdistributionで設定します.主にrandom、zipf、normalなどが含まれ、デフォルトはrandomです.
また注意しなければならないのはblock size、つまりI/O操作の大きさで、通常は同じblockを読み書きで使用しています.例えばbs=4 kですが、実際には違います.bs=4 k、16 kで読み書きを4 kに設定できますが、書くのは16 kです.
libaio engineではiodepthの設定も考慮する必要があり、syncなどではjobnumを設定してfioを複数のスレッドで同時にディスクをテストさせる必要がある.テストが多くなると、libaioは簡単にディスクを殺すことができますが、syncはいくつかのスレッドを起動する必要があります.の

結果分析

fioが完了すると、実行fio -ioengine=psync -filename=iotest -bs=8k -fdatasync=1 -rw=write -size=10g -runtime=60 -name="pingcap"が出力するなど、対応する結果が生成されます.

pingcap: (g=0): rw=write, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=296MiB/s][r=0,w=37.8k IOPS][eta 00m:00s]
pingcap: (groupid=0, jobs=1): err= 0: pid=39086: Thu Apr 12 16:49:02 2018
  write: IOPS=37.0k, BW=297MiB/s (311MB/s)(10.0GiB/34510msec)
    clat (usec): min=3, max=159, avg= 5.28, stdev= 1.58
     lat (usec): min=3, max=159, avg= 5.40, stdev= 1.59
    clat percentiles (nsec):
     |  1.00th=[ 4048],  5.00th=[ 4192], 10.00th=[ 4256], 20.00th=[ 4384],
     | 30.00th=[ 4448], 40.00th=[ 4512], 50.00th=[ 4768], 60.00th=[ 5344],
     | 70.00th=[ 5472], 80.00th=[ 5664], 90.00th=[ 6176], 95.00th=[ 8512],
     | 99.00th=[10688], 99.50th=[11328], 99.90th=[21632], 99.95th=[22912],
     | 99.99th=[27520]
   bw (  KiB/s): min=291856, max=348720, per=100.00%, avg=317689.68, stdev=14463.28, samples=66
   iops        : min=36482, max=43590, avg=39711.20, stdev=1807.88, samples=66
  lat (usec)   : 4=0.37%, 10=96.95%, 20=2.51%, 50=0.17%, 100=0.01%
  lat (usec)   : 250=0.01%
  cpu          : usr=8.55%, sys=43.65%, ctx=1310832, majf=0, minf=149
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.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.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=0,1310720,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=297MiB/s (311MB/s), 297MiB/s-297MiB/s (311MB/s-311MB/s), io=10.0GiB (10.7GB), run=34510-34510msec

Disk stats (read/write):
  nvme0n1: ios=0/1306428, merge=0/22, ticks=0/18431, in_queue=17280, util=50.11%

非常に強力なOptaneディスクの上にsync engineを使用して、毎回syncでディスクを書きますが、性能はまだ悪く、300 MB未満で、他のディスクはもっと悪いかもしれません.私たちは主にいくつかの指標に注目しています.
slat/clat/lat:これらはlatency指標であり、slatはSubmission latencyであり、つまり実際にI/Oを実行するまでの時間であり、syncテストではこれはありません.slatはclatであるからです.clatはCompletion latency、すなわちコミットから完了までの時間です.latはTotal latencyであり、fioがこのI/Oユニットの作成から完了までの合計時間を含む.
また注目すべき指標はBWとIOPSであり,この2つは直感的で説明しない.一番下はios、つまり総I/O操作回数、mergeはI/Oスケジューリングでマージされた回数、ticksはディスクを忙しく保つ回数、in_Queueはディスクキュー全体にかかる時間であり、utilはディスクの利用率である.

その他

コンソールで最後の要約情報を出力するだけでなく、fioは中間の操作をファイルに出力し、ツールを使用してグラフ表示を描画します.通常はwrite_を設定します.bw_log,write_bw_logとwrite_iops_log、それからfio_generate_plotsを使って絵を描きます.またfio2gnuplotを使って描くこともできます.ネット上には多くのチュートリアルがありますが、ここでは言いません.
また、fioはblktraceで生成したファイルを再生して、実際のシステムのI/O問題を特定して、これは後でよく検討することができます.
総じて言えば、fioは非常に強力なツールであり、使い終わったら、個人のI/Oに対する理解はもっと深くなり、同時にハードウェア資源に基づいてシステムを最適化することができます.