☰

Linuxでは、SSDランダム読み取りパフォーマンスが悪い。

tag-icon • tag-icon performance ssd
Linuxでは、SSDランダム読み取りパフォーマンスが悪い。

最近1つ受け取りました。インテル320シリーズSSD、ランダム4K読み取り用に広告された38K IOPSを達成するのに苦労しました。

どちらも一緒に来ます。fio私自身のハッキングプログラムを使用すると、約6K IOPSを確認しました。 IOの深さのサイズが重要ではないのとほぼ同じです。カーネルは一度に1つのブロックを取得しようとします。

例:

$ cat job
[randread]
filename=/dev/sdb2
rw=randread
size=128m
blocksize=4k
ioengine=libaio
iodepth=64
direct=1

$ sudo fio job
randread: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [25423K/0K /s] [6207/0 iops] [eta 00m:00s]
randread: (groupid=0, jobs=1): err= 0: pid=4678
  read : io=131072KB, bw=24852KB/s, iops=6213, runt=  5274msec
    slat (usec): min=1, max=94, avg= 5.00, stdev= 2.88
    clat (usec): min=312, max=13070, avg=10290.25, stdev=1399.78
    bw (KB/s) : min=23192, max=24464, per=97.08%, avg=24125.60, stdev=383.70
  cpu          : usr=15.74%, sys=22.57%, ctx=31642, majf=0, minf=88
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=99.8%
     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.1%, >=64=0.0%
     issued r/w: total=32768/0, short=0/0
     lat (usec): 500=0.01%, 750=0.01%, 1000=0.03%
     lat (msec): 2=0.05%, 4=0.10%, 10=20.10%, 20=79.70%

Run status group 0 (all jobs):
   READ: io=131072KB, aggrb=24852KB/s, minb=25448KB/s, maxb=25448KB/s, mint=5274msec, maxt=5274msec

Disk stats (read/write):
  sdb: ios=30453/0, merge=850/0, ticks=319060/0, in_queue=319060, util=98.09%

システムはLinux 2.6.35-31-generic #63-Ubuntu SMP Mon Nov 28 19:29:10 UTC 2011 x86_64 GNU/Linux80GB /dev/sdb2SSDの〜10GBパーティションです。fio1.38バージョンです。

何が間違っているのかについてのどんなアイデアにも感謝します。

PS：上記のテスト（）のパーティションは/dev/sdb24K境界に揃っています。より大きな範囲（サイズ= 10 g）で読むことは役に立ちません。

ベストアンサー1

ディスカッションを見るファイルシステムのキャッシュにLinuxシステムをより積極的に構成できますか？

つまり、一部のデバイスキュー設定を調整する必要があります。カーネルがスケジューラやキュー設定を誤って推測したり、手動で設定しているようです。

努力する

grep . /sys/block/sd*/{queue/{nr_requests,nomerges,rotational,scheduler},device/queue_depth}

そして

lsblk

問題をデバッグします。 NCQが原因で単一の読み取り待ち時間を許可できる場合は、queue_depthこれを31以上に設定する必要があります。これは0でなければならず、SSDの場合は0でなければなりません。正しいものを選ぶのは難しいですが、生のIOPSには十分でしょう。私が見つけたnr_requestsnomergesrotationalschedulernoop正しい調整 cfq実際の要件をよりよく処理します。

そして、ディスクがSATA + AHCIで接続され、NCQが有効になっていることを確認してください。それ以外の場合、ディスクからすべてを取り出す可能性はほとんどありません。

おすすめ記事