web-dev-qa-db-ja.com

IO書き込みに対するLinuxバッファキャッシュの影響？

Linuxサーバー上の2つのファイルシステム（カーネル2.6.37、16コア、32G RAM）間で大きなファイル（3 x 30G）をコピーしていますが、パフォーマンスが低下しています。バッファキャッシュの使用がI/Oパフォーマンスを低下させているのではないかと思います。

問題を絞り込むために、SASディスクで直接fioを使用して、パフォーマンスを監視しました。

2つのfio実行の出力は次のとおりです（最初はdirect = 1、2番目はdirect = 0）：

構成：

[test]
rw=write
blocksize=32k
size=20G
filename=/dev/sda
# direct=1

実行1：

test: (g=0): rw=write, bs=32K-32K/32K-32K, ioengine=sync, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [W] [100.0% done] [0K/205M /s] [0/6K iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=4667
  write: io=20,480MB, bw=199MB/s, iops=6,381, runt=102698msec
    clat (usec): min=104, max=13,388, avg=152.06, stdev=72.43
    bw (KB/s) : min=192448, max=213824, per=100.01%, avg=204232.82, stdev=4084.67
  cpu          : usr=3.37%, sys=16.55%, ctx=655410, majf=0, minf=29
  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 r/w: total=0/655360, short=0/0
     lat (usec): 250=99.50%, 500=0.45%, 750=0.01%, 1000=0.01%
     lat (msec): 2=0.01%, 4=0.02%, 10=0.01%, 20=0.01%

Run status group 0 (all jobs):
  WRITE: io=20,480MB, aggrb=199MB/s, minb=204MB/s, maxb=204MB/s, mint=102698msec,    maxt=102698msec

Disk stats (read/write):
  sda: ios=0/655238, merge=0/0, ticks=0/79552, in_queue=78640, util=76.55%

実行2：

test: (g=0): rw=write, bs=32K-32K/32K-32K, ioengine=sync, iodepth=1
Starting 1 process
Jobs: 1 (f=1): [W] [100.0% done] [0K/0K /s] [0/0 iops] [eta 00m:00s]     
test: (groupid=0, jobs=1): err= 0: pid=4733
  write: io=20,480MB, bw=91,265KB/s, iops=2,852, runt=229786msec
    clat (usec): min=16, max=127K, avg=349.53, stdev=4694.98
    bw (KB/s) : min=56013, max=1390016, per=101.47%, avg=92607.31, stdev=167453.17
  cpu          : usr=0.41%, sys=6.93%, ctx=21128, majf=0, minf=33
  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 r/w: total=0/655360, short=0/0
     lat (usec): 20=5.53%, 50=93.89%, 100=0.02%, 250=0.01%, 500=0.01%
     lat (msec): 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.12%
     lat (msec): 100=0.38%, 250=0.04%

Run status group 0 (all jobs):
  WRITE: io=20,480MB, aggrb=91,265KB/s, minb=93,455KB/s, maxb=93,455KB/s, mint=229786msec, maxt=229786msec

Disk stats (read/write):
  sda: ios=8/79811, merge=7/7721388, ticks=9/32418456, in_queue=32471983, util=98.98%

結果を解釈するのに十分なfioの知識はありませんが、バッファキャッシュを使用した場合の全体的なパフォーマンスがO_DIRECTの場合よりも50％低くなるとは思いません。

誰かがfio出力の解釈を手伝ってもらえますか？
問題を修正/最小化できるカーネル調整はありますか？

どうもありがとう、

linuxcachelinux-kernel
5
Patrick LeBoutillier

O_DIRECTを使用すると、カーネルは通常のキャッシュメカニズムをすべてバイパスし、ディスクに直接書き込みます。 O_SYNCを使用していないため、キャッシュが有効になっている場合（O_DIRECTを使用していない場合）、カーネルは「ええ、ええ、私はそれを作成しました。心配しないでください！」と嘘をつく可能性があります。ディスクに書き込みます。一部のキャッシュ（ディスクキャッシュ/ページキャッシュ/ ...）にのみ書き込まれます。

2
Zoltan

直接実行すると、コピーに時間を費やさないため、直接I/Oを高速化することは不可能ではありませんが、2回目の実行の完了時間の広がりが最初の実行の完了時間よりもはるかに長く、結果は奇妙に見えます。また、ディスク統計を比較します。

sda: ios=0/655238, merge=0/0, ticks=0/79552, in_queue=78640, util=76.55%

vs

 sda: ios=8/79811, merge=7/7721388, ticks=9/32418456, in_queue=32471983, util=98.98%

最初の実行では、2番目の実行でI/Oのマージ（merge =）は実行されませんでした。最初の実行中、ディスクは完全にビジーではなく（util =）、2回目の実行では非常にビジーでした。 in_queue 2回目の実行の時間も長く、I/Oがカーネルでバックアップされていたことを示しています。奇妙な-おそらくライトバックはどういうわけか壊れていましたか？ I/Oスケジューラをnoopまたはdeadlineに変更することで問題を回避できる可能性がありますが、バグがあるように見えます...

0
Anon