☰

X9DR3-F の NVMe ドライブで予想外のパフォーマンス低下

tag-icon • tag-icon raid performance nvme
X9DR3-F の NVMe ドライブで予想外のパフォーマンス低下

サーバーの NVMe SSD ストライプで、異常に低いパフォーマンスが発生しているようです。ハードウェアは次のとおりです。

  • マザーボード: X9DR3-F
  • CPU: デュアル E5-2650v2
  • RAM: 128GB DDR3-1333 UDIMM (16x8GB)
  • NVMe ドライブ: 分岐レーンを備えた PCIe エクスパンダー経由の 4x MZVLB256HBHQ-000L7

lspci -nvvデバイスの 8GT/s x4 リンクが表示され、ドライブが要求するように PCIe 3.0 で動作していることがわかります。 LnkSta: Speed 8GT/s, Width x4このドライブのベンチマークでは、約 1.4GB/s の書き込み速度で動作できることが示されています。

ドライブへのシーケンシャル書き込みを試みると、そのパフォーマンスの約 3 分の 1 しか得られません。次の図は、書き込み中に 619MB/秒を示しており、その後、おそらくデータが完全にディスクにフラッシュされるまでにさらに 50 秒間停止しています。

$ sudo dd if=/dev/zero of=/dev/nvme1n1 bs=16M count=1k status=progress
16726884352 bytes (17 GB, 16 GiB) copied, 27 s, 619 MB/s
1024+0 records in
1024+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 71.8953 s, 239 MB/s

これは私の合成ベンチマークと他の人の合成ベンチマークの単なる違いだと仮定して、4 つのデバイスすべてを MD RAID-0 に入れて、もう一度試してみました。

$ sudo mdadm --create /dev/md0 --level=0 --raid-devices=4 --force --run /dev/nvme?n1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
$ sudo dd if=/dev/zero of=/dev/md0 bs=16M count=2k status=progress
34191966208 bytes (34 GB, 32 GiB) copied, 57 s, 600 MB/s
2048+0 records in
2048+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 79.7502 s, 431 MB/s

改善されましたが、まだまだ改善の余地があります。公立学校で学んだ計算を信じるなら、これらのドライブは 430x10 から 600x10 メガビット/秒の間で転送しており、最良のシナリオは 6 ギガビットです。理想的な状況では、他の合成ベンチマークに基づくと、単純なオール 0 ストライプ書き込みで 4 台のドライブが 6 ギガバイトに達すると予想されます。これはシステムの制限にすぎないと仮定して、無関係の 40 ギガビット イーサネット カードを別のホストでテストしました。

$ iperf -c 10.x.x.x -P 4
------------------------------------------------------------
Client connecting to 10.x.x.x, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  2] local 10.x.x.x port 53750 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/196)
[  1] local 10.x.x.x port 53754 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/132)
[  3] local 10.x.x.x port 53738 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/212)
[  4] local 10.x.x.x port 53756 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/107)
[ ID] Interval       Transfer     Bandwidth
[  2] 0.0000-10.0027 sec  12.4 GBytes  10.6 Gbits/sec
[  1] 0.0000-10.0180 sec  12.7 GBytes  10.9 Gbits/sec
[  3] 0.0000-10.0179 sec  10.6 GBytes  9.05 Gbits/sec
[  4] 0.0000-10.0180 sec  10.5 GBytes  8.97 Gbits/sec
[SUM] 0.0000-10.0011 sec  46.1 GBytes  39.6 Gbits/sec

このネットワーク カードは SSD のパフォーマンスとは関係ありませんが、特にこのカードが 4x4 ではなく x8 リンクであるため、システムが PCIe 経由で少なくとも 40gbit リンクを飽和させることができることを示しています。 注目すべき点の 1 つは、イーサネット カードが CPU1_SLOT1 にあり、SSD が CPU2_SLOT4 にあることです。 ただし、SLOT4 は CPU2 から直接接続され、SLOT1 は CPU1 から直接接続されるため、パフォーマンスに大きな違いが生じるかどうかはわかりません。CPU 間にはデュアル 8GT/s QPI リンクがあり、追加のスイッチはありません。 X9DR3-F ブロック図

私にとって、読み取りパフォーマンスもそれに応じて低いことは注目に値します。ここではファイルシステムのオーバーヘッドはなく、これは単に生のフラッシュと PCIe のパフォーマンスが影響しているだけです。これは、低性能のハードウェアでの RAID-5 の 4x コンシューマー SATA HDD の読み取りパフォーマンスに関するもので、まったく許容できないほど遅いです。

$ sudo dd if=/dev/md0 of=/dev/null bs=16M count=8k
8192+0 records in
8192+0 records out
137438953472 bytes (137 GB, 128 GiB) copied, 214.738 s, 640 MB/s

topこの読み取り操作中に確認したところdd、CPU が 100% 消費され、そのうち 97% がシステム待機状態でした。他の 31 個のスレッドは、ほぼアイドル状態でした。ここで発生したパフォーマンスの問題の診断はどこから始めればよいのでしょうか?

これはDDだけの問題だと仮定して、fioで再度試してみました。MDデバイスはそのままにして、デフォルト設定を選択できるようにXFSでフォーマットし、マウントして、https://cloud.google.com/compute/docs/disks/benchmarking-pd-performance:

シーケンシャル書き込み

Run status group 0 (all jobs):
  WRITE: bw=1348MiB/s (1414MB/s), 1348MiB/s-1348MiB/s (1414MB/s-1414MB/s), io=80.8GiB (86.7GB), run=61368-61368msec

Disk stats (read/write):
    md0: ios=0/710145, merge=0/0, ticks=0/397607236, in_queue=397607236, util=99.82%, aggrios=0/177558, aggrmerge=0/2, aggrticks=0/99452549, aggrin_queue=99465067, aggrutil=99.62%
  nvme0n1: ios=0/177568, merge=0/5, ticks=0/56627328, in_queue=56635784, util=97.96%
  nvme3n1: ios=0/177536, merge=0/1, ticks=0/145315089, in_queue=145331709, util=99.62%
  nvme2n1: ios=0/177559, merge=0/3, ticks=0/151148103, in_queue=151165889, util=99.44%
  nvme1n1: ios=0/177569, merge=0/0, ticks=0/44719677, in_queue=44726889, util=97.87%

ランダム書き込み

Run status group 0 (all jobs):
  WRITE: bw=101MiB/s (106MB/s), 101MiB/s-101MiB/s (106MB/s-106MB/s), io=6074MiB (6370MB), run=60003-60003msec

Disk stats (read/write):
    md0: ios=0/1604751, merge=0/0, ticks=0/623304, in_queue=623304, util=100.00%, aggrios=0/401191, aggrmerge=0/2, aggrticks=0/153667, aggrin_queue=153687, aggrutil=99.99%
  nvme0n1: ios=0/402231, merge=0/3, ticks=0/156754, in_queue=156775, util=99.98%
  nvme3n1: ios=0/401144, merge=0/2, ticks=0/149648, in_queue=149667, util=99.98%
  nvme2n1: ios=0/400158, merge=0/0, ticks=0/150380, in_queue=150400, util=99.98%
  nvme1n1: ios=0/401233, merge=0/4, ticks=0/157887, in_queue=157908, util=99.99%

シーケンシャル読み取り

Run status group 0 (all jobs):
   READ: bw=6244MiB/s (6547MB/s), 6244MiB/s-6244MiB/s (6547MB/s-6547MB/s), io=367GiB (394GB), run=60234-60234msec

Disk stats (read/write):
    md0: ios=3089473/14, merge=0/0, ticks=272954324/220, in_queue=272954544, util=99.98%, aggrios=779529/3, aggrmerge=6/1, aggrticks=68744470/104, aggrin_queue=68744621, aggrutil=99.60%
  nvme0n1: ios=779520/6, merge=12/2, ticks=24023533/1, in_queue=24023534, util=98.84%
  nvme3n1: ios=779519/2, merge=14/0, ticks=145571896/378, in_queue=145572449, util=99.60%
  nvme2n1: ios=779536/3, merge=0/1, ticks=77038488/3, in_queue=77038492, util=98.90%
  nvme1n1: ios=779544/3, merge=0/1, ticks=28343963/34, in_queue=28344012, util=98.81%

ランダム読み取り

Run status group 0 (all jobs):
   READ: bw=372MiB/s (390MB/s), 372MiB/s-372MiB/s (390MB/s-390MB/s), io=21.8GiB (23.4GB), run=60002-60002msec

Disk stats (read/write):
    md0: ios=5902401/10, merge=0/0, ticks=2684388/0, in_queue=2684388, util=100.00%, aggrios=1475009/3, aggrmerge=608/0, aggrticks=685706/0, aggrin_queue=685706, aggrutil=99.90%
  nvme0n1: ios=1475288/4, merge=632/1, ticks=697246/0, in_queue=697246, util=99.89%
  nvme3n1: ios=1475328/2, merge=611/0, ticks=678849/1, in_queue=678850, util=99.89%
  nvme2n1: ios=1474625/3, merge=588/1, ticks=673908/0, in_queue=673909, util=99.90%
  nvme1n1: ios=1474795/3, merge=602/0, ticks=692822/1, in_queue=692822, util=99.90%

これらははるかに高速で、アレイに対して複数のスレッドが優位に立つという利点があることを示していますが、オンラインの他のベンチマークでは、これらのドライブが個別に 1GB/秒の書き込みを行っていることが示されています (一方、4 つすべてを合わせると 1.4GB/秒がピークです)。また、UserBenchmark の結果では、読み取りがドライブあたり 2.2GB/秒となっているため、6GB/秒の読み取りはコンテキスト内ではかなり良好です。

では、単一プロセスのパフォーマンスを向上させるために何かできることはありますか?

答え1

Samsung MZVLB256HBHQ-000L7は小型SSD（256GB）なので、複数GBにまたがる書き込みでは内部NAND帯域幅のボトルネックに陥ります。これをトリミングすることができます（ドライブに現在保存されているすべてのデータが失われます) を使用すると、内部の pSLC キャッシュがクリーンになり、最初のベンチマークでは帯域幅が拡大しますが、すぐに再び飽和状態になります。

答え2

Samsung MZVL*ドライブの私の経験は最悪です。https://superuser.com/questions/1721288/ssd-performance-falls-off-a-cliff

ドライブの信頼できる仕様を見つけようとしていますが、私の推測では、ドライブに DRAM が不足しているようです。

答え3

まあ、そうするのは嫌ですが、最終的には答えて質問を締めくくるべきです。PM981はする512MB の DRAM キャッシュがあり、12GB の SLC キャッシュも備えているため、高速です。RAID-0 で 4 台構成にすると、素晴らしいパフォーマンスを発揮します。

https://www.techpowerup.com/ssd-specs/samsung-pm981a-256-gb.d784

問題は解決できなかったので、代わりに NAS を購入しました。

関連情報