Ich erlebe eine scheinbar ungewöhnlich niedrige Leistung eines NVMe-SSD-Streifens in einem Server. Die Hardware ist wie folgt:
- Hauptplatine: X9DR3-F
- CPU: Dual E5-2650v2
- Arbeitsspeicher: 128 GB DDR3-1333 UDIMM (16 x 8 GB)
- NVMe-Laufwerke: 4x MZVLB256HBHQ-000L7 über PCIe-Expander mit gegabelten Lanes
lspci -nvvzeigt eine 8GT/s x4-Verbindung für ein Gerät und zeigt, dass es mit PCIe 3.0 läuft, wie es das Laufwerk will: LnkSta: Speed 8GT/s, Width x4Benchmarks für dieses Laufwerk zeigen, dass es Schreibgeschwindigkeiten von etwa 1,4 GB/s erreicht.
Wenn ich sequenzielle Schreibvorgänge auf das Laufwerk ausführe, erreiche ich etwa ein Drittel dieser Leistung. Im Folgenden sind 619 MB/s beim Schreiben zu sehen, dann eine weitere Pause von 50 Sekunden, vermutlich während die Daten vollständig auf die Festplatte geschrieben wurden.
$ 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
Da ich davon ausging, dass es sich dabei nur um eine Eigenart meines synthetischen Benchmarks im Vergleich zum synthetischen Benchmark von jemand anderem handelte, habe ich alle 4 Geräte in ein MD RAID-0 gesteckt und es erneut versucht:
$ 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
Besser, aber viel zu wünschen übrig. Wenn man meinen Mathematikkenntnissen aus der öffentlichen Schulzeit Glauben schenken darf, übertragen diese Laufwerke irgendwo zwischen 430 x 10 und 600 x 10 Megabit pro Sekunde, also im besten Fall 6 Gbit. Unter idealen Bedingungen würde ich erwarten, dass 4x-Laufwerke bei einfachen Stripe-Writes mit nur 0 6 GByte erreichen, basierend auf synthetischen Benchmarks von anderen. In der Annahme, dass dies nur eine Einschränkung des Systems war, habe ich die unabhängige 40-Gbit/s-Ethernet-Karte mit einem anderen Host getestet:
$ 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
Obwohl diese Netzwerkkarte nichts mit der SSD-Leistung zu tun hat, zeigt sie mir, dass das System in der Lage ist, mindestens eine 40-Gbit-Verbindung über PCIe zu sättigen, insbesondere, da es sich bei dieser Karte nur um eine x8-Verbindung statt einer 4x4-Verbindung handelt. Bemerkenswert ist möglicherweise, dass sich die Ethernet-Karte auf CPU1_SLOT1 und die SSDs auf CPU2_SLOT4 befinden. Ich bin mir jedoch nicht sicher, ob das den enormen Leistungsunterschied erklären würde, da SLOT4 direkt an CPU2 hängt und SLOT1 direkt an CPU1. Es gibt eine duale 8GT/s QPI-Verbindung zwischen den CPUs und keine zusätzlichen Switches:
Für mich ist es bemerkenswert, dass auch die Leseleistung entsprechend niedrig ist. Es gibt hier keinen Dateisystem-Overhead, das ist nur die reine Flash- und PCIe-Leistung. Dies entspricht in etwa der Leseleistung von 4x Consumer-SATA-Festplatten in RAID-5 auf schlechterer Hardware, also einfach absolut inakzeptabel langsam:
$ 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
Die Überprüfung topwährend dieses Lesevorgangs ergab, dddass 100 % der CPU-Leistung verbraucht wurden, davon 97 % durch Systemwartezeit. Die anderen 31 Threads waren mehr oder weniger im Leerlauf. Wo kann ich mit der Diagnose der hier aufgetretenen Leistungsprobleme beginnen?
Da ich annahm, dass dies nur ein Problem mit DD war, versuchte ich es erneut mit fio. Ich behielt das MD-Gerät, formatierte es mit XFS, sodass es die Standardeinstellungen wählen konnte, mountete es und führte die unterhttps://cloud.google.com/compute/docs/disks/benchmarking-pd-performance:
Sequentielles Schreiben
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%
Zufälliges Schreiben
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%
Sequentielles Lesen
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%
Zufälliges Lesen
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%
Diese sind viel schneller, was zeigt, dass es von Vorteil ist, wenn mehrere Threads auf das Array einwirken. Andere Benchmarks im Internet haben jedoch wiederum gezeigt, dass diese Laufwerke einzeln 1 GB/s beim Schreiben erreichen (wohingegen ich bei allen 4 zusammen einen Spitzenwert von 1,4 GB/s erreiche). Außerdem habe ich bei UserBenchmark-Ergebnissen Lesegeschwindigkeiten von 2,2 GB/s pro Laufwerk gesehen. 6 GB/s beim Lesen sind also in diesem Kontext ein ziemlich guter Wert.
Kann man dann etwas tun, um die Leistung einzelner Prozesse zu verbessern?
Antwort1
Samsung MZVLB256HBHQ-000L7 sind kleine SSDs (256 GB), daher stoßen Sie bei Schreibvorgängen über mehrere GB auf den internen NAND-Bandbreitenengpass. Sie können sie kürzen (Verlust aller aktuell auf den Laufwerken gespeicherten Daten), um den internen pSLC-Cache zu leeren. Dadurch wird für die ersten Benchmarks mehr Bandbreite benötigt, die ihn jedoch schnell wieder überlastet.
Antwort2
Meine Erfahrungen mit Samsung MZVL*-Laufwerken sind miserabel. Siehehttps://superuser.com/questions/1721288/ssd-performance-falls-off-a-cliff
Ich versuche, seriöse Spezifikationen für Ihr Laufwerk zu finden, aber ich vermute hauptsächlich, dass den Laufwerken DRAM fehlt.
Antwort3
Nun, ich tue es ungern, aber letztendlich sollte ich die Frage beantworten und schließen. Der PM981 fährtTunverfügen über einen 512 MB DRAM-Cache und bieten außerdem einen 12 GB SLC-Cache, also sollten sie schnell sein. Vier davon in einem RAID-0 sollten der Hammer sein.
https://www.techpowerup.com/ssd-specs/samsung-pm981a-256-gb.d784
Ich habe stattdessen einfach ein NAS gekauft, da ich dieses Problem nie lösen konnte.