☰

fio seq_writesがddよりはるかに速いのはなぜですか？

tag-icon • tag-icon performance dd zfs storage
fio seq_writesがddよりはるかに速いのはなぜですか？

理解するために、いくつかの愚かなテストを実行しているzfsサーバーがありますが、これは私を混乱させます。

コンテキスト： - FreeBSD 11.2、圧縮が有効なZFS、SAS HDD、RAIDz2、768GB RAM。

どちらのコマンドも FreeBSD サーバーで直接実行されます。

# time dd if=/dev/random of=./test_file bs=128k count=131072 
131072+0 records in
131072+0 records out
17179869184 bytes transferred in 135.191596 secs (127077937 bytes/sec)
0.047u 134.700s 2:15.19 99.6%   30+172k 4+131072io 0pf+0w

# #The result file size:
# du -sh test_file 
  16G   test_file

これは、ランダムデータを含む16GiBファイルを約135秒で処理できたことを示しています。 117MiB/秒

今試してみます。ペオ、

# fio --name=seqwrite --rw=write --bs=128k --numjobs=1 --size=16G --runtime=120 --iodepth=1 --group_reporting
seqwrite: (g=0): rw=write, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=psync, iodepth=1
fio-3.6
Starting 1 process
seqwrite: Laying out IO file (1 file / 16384MiB)
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=2482MiB/s][r=0,w=19.9k IOPS][eta 00m:00s]
seqwrite: (groupid=0, jobs=1): err= 0: pid=58575: Wed Jul 25 09:38:06 2018
  write: IOPS=19.8k, BW=2478MiB/s (2598MB/s)(16.0GiB/6612msec)
    clat (usec): min=28, max=2585, avg=48.03, stdev=24.04
     lat (usec): min=29, max=2586, avg=49.75, stdev=25.19
   bw (  MiB/s): min= 2295, max= 2708, per=99.45%, avg=2464.33, stdev=124.56, samples=13
   iops        : min=18367, max=21664, avg=19714.08, stdev=996.47, samples=13
---------- Trimmed for brevity -------------
Run status group 0 (all jobs):
  WRITE: bw=2478MiB/s (2598MB/s), 2478MiB/s-2478MiB/s (2598MB/s-2598MB/s), io=16.0GiB (17.2GB), run=6612-6612msec

これでスループットが2478MiB / sに達しました。また、任意のデータと同じ16GiBファイルを使用します。

なぜそんなに大きな違いがありますか？私が理解したように、ddコマンドはcreatecallを使用してファイルを生成して実行する必要があり、open呼び出しwriteは開いているファイルにランダムなデータを書き込みます。最後にファイルがありますclose。 ZFSのデフォルトレコードサイズに合わせて128Kのブロックサイズを選択しました。

fioテストは通貨のみを測定する必要がありますwriteが、他のものはすべて同じです。スループットの違いはなぜそんなに大きいのですか？

より混乱するのは、50％圧縮でファイルを生成するようにfioに要求すると、スループットが847MiB / sに低下することです。圧縮にはCPU操作が含まれているため、スループットが低下することがわかりますが、データ量のほぼ半分を記録してそれを相殺したいと思います。なぜそんなに大きな影響を与えるのか分かりますか？

50％圧縮でfioを実行するコマンド：

 fio --name=seqwrite --rw=write --bs=128k --numjobs=1 --size=16G --runtime=60 --iodepth=1 --buffer_compress_percentage=50 --buffer_pattern=0xdeadbeef --group_reporting

ベストアンサー1

いくつかの文脈を強調するために、あなたの質問を再構築します。

なぜ？

fio --name=seqwrite --rw=write --bs=128k --numjobs=1 --size=16G --runtime=120 --iodepth=1 --group_reporting

より速い

time dd if=/dev/random of=./test_file bs=128k count=131072

768GB RAM、SAS HDD、およびZFS圧縮が有効なRAIDZ2で構成されたFreeBSD 11.2システムでは？

主な違いは、fioがテストを開始する前にファイルを事前に生成することです。

seqwrite: Laying out IO file (1 file / 16384MiB)

代わりにddファイル拡張子の書き込みが発生する可能性があります（これによりメタデータの更新が発生します）。また、RAM（768G）が多すぎますが（16G）に比べて書き込むデータがほとんどないため、書き込みがRAMに保持される可能性が高くなります（実際にははるかに後でディスクに書き込まれません）。fioファイルが事前に作成されていて、各I / Oに対して変更する必要があるファイルメタデータがほとんどない場合、これが発生する可能性があります。少なくとも記録されたすべてのデータがカーネルに書き戻されたときに、操作が完了するまで完了したとは言わないようにfioに指示できます。end_fsync=1。

（注：ディスクが実行できることがわかっているよりもはるかに低い完了遅延時間を見ると、I / Oがバッファリング中であるという微妙なヒントがあります。

clat(usec): 最小=28, 最大=2585, 平均=48.03, stdev=24.04

回転ディスクは実際に28マイクロ秒以内にI / O操作を完了できますか？そうでなければ、おそらくどこかにバッファリングされているでしょう）

ついに、fio はデフォルトで後続のブロックで同じパターンを再利用します。。圧縮が行われるため、fioスループットがさらに向上します（ただし、ZFSレコードサイズなどの要因によって異なります）。これを確認するには、fioにバッファを圧縮できないようにし（最終的にオンrefill_buffers）、スループットが低下することを確認するように指示します（あなたの場合はそうです）。

長すぎます。あなたが提供したとfioコマンドはdd同じものをテストしません。ファイルがすでに正しいサイズで存在するかどうか、作成中のデータがどれだけ圧縮可能であるか、データがすべて書き戻されたかどうかを確認せずに、あまりにも少ないデータを記録してカーネルバッファリングを検討しているかどうかなどの注意に注意する必要があります。ディスク。

おすすめ記事