5つのToshibaPx04Srb192 SSD(仕様による270Kランダム読み取りIOP)があり、ハードウェアRaid5でセットアップされています。 fioを実行すると、25万のIOPSが得られます。これは、私が期待していたものをはるかに下回っています。
/fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/ae/disk1/test --bs=4k --iodepth=96 --numjobs=1 --size=8g --readwrite=randread
test: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=96
fio-2.0.9
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [961.6M/0K /s] [246K/0 iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=342604: Tue Feb 12 23:58:01 2019
read : io=8192.0MB, bw=991796KB/s, iops=247948 , runt= 8458msec
cpu : usr=10.88%, sys=87.74%, ctx=437, majf=0, minf=115
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%
issued : total=r=2097152/w=0/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
READ: io=8192.0MB, aggrb=991795KB/s, minb=991795KB/s, maxb=991795KB/s, mint=8458msec, maxt=8458msec
Disk stats (read/write):
sdb: ios=2083688/0, merge=0/0, ticks=265238/0, in_queue=265020, util=98.53
lspci -nn | grep RAID
18:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3508 [1000:0016] (rev 01)
5つのSSDIOPSが個々のSSDの少なくとも2倍になると予想していました。そうですか? IOPが低い理由について何か提案はありますか?
(fioのバージョンは古いです! https://github.com/axboe/fio/releases を参照して、アップストリームが到達したものを確認してください...)
他の回答で得られるフィードバックは良いですが、これを強調したいと思います。
cpu : usr=10.88%, sys=87.74%, ctx=437, majf=0, minf=115
ユーザースペースとカーネルシステムのパーセンテージを合計すると、98.62%になります。 I/Oを送信するためのCPU時間が残っていないことを強くお勧めします(通常は推奨しないgtod_reduce=1
の高速ストライプをすでに使用していることに注意してくださいが、あなたの場合は適切に見えます) 。
しかし、他にもいくつかあります...
sdb: ios=2083688/0, merge=0/0, ticks=265238/0, in_queue=265020, util=98.53
これは、RAIDコントローラーが提示している「ディスク」が非常にビジーであることを示唆しています(そのutil
パーセンテージを見てください)。それは心に留めておくべきことです。
ファイルシステム(/ae/disk1/
)内のファイルを介してI/Oを実行していますか?もしそうなら、ファイルシステムがいくらかのオーバーヘッドを課し、あなたが期待しているO_DIRECT
の振る舞いを提供しないかもしれないことを知っていますか?おそらく、ブロックレベル(つまり/dev/sdb
)でI/Oを実行することから始めて、オーバーヘッドが何であるかを特定できるように作業を進めます(警告:注意してください-fioは誤用されるとデータを破壊する可能性があります)。
あなたが本当に速く行くつもりなら、私はあなたがする必要があると思います:
numjobs
を増やすことによって)。そうすれば、fioスレッド/プロセスは異なるCPUに移行する可能性が高くなります(ただし、すべてにコストがかかることに注意してください)...私が述べたように、ほとんどの人がこれらの長さに行く必要があることはまれですが、おそらくあなたは例外の1つです:-)。 fioメーリングリストのスレッド応答 " Re:ストレステストPCI-Eに推奨されるジョブファイル "はこれについて言及しています:
プロセスではなくスレッド(スレッド)を使用すると、メリット(ディスクあたりの負荷が増える)が見られる場合があります。また、ディスクごとに複数のスレッドを使用する必要がある場合もあります。その他のオプションについては、 http://fio.readthedocs.io/en/latest/fio_doc.html を参照してください。 https://www.spinics.net/lists/fio/msg05451.html と http://marc.info/?l=linux-kernel&m=140313968523237&w=2 の両方= fioを使用して高負荷を駆動する人々の例を挙げてください。
まず、仕様に従って270k iopsを期待しますが、この値を満たすために必要なブロックサイズはどれくらいですか?スペックでは実際には4kioサイズですか?
次に、単一のioスレッドを使用してraid5のベンチマークを行う場合、raid5の全体的な読み取りパフォーマンスを表示することはできません。各読み取りioは、1つのSSDドライブによってのみ提供されます。したがって、ワーカー数(fio numjobsパラメーター)を少なくとも5に増やす必要があります。