NVME Performance debuggen / optimieren

[h^2]

Der neue Fileserver wird langsam eingerichtet. Doch bevor ich den zpool erzeuge, dachte ich, ich benchmarke erstmal "roh" die Platten.

Es sind verbaut

<Lexar SSD NM790 4TB 12237>        at scbus5 target 0 lun 1 (pass1,nda0)
<CT4000P3PSSD8 P9CR40A>            at scbus6 target 0 lun 1 (pass2,nda1)
<CT4000P3PSSD8 P9CR40A>            at scbus7 target 0 lun 1 (pass3,nda2)
<Lexar SSD NM790 4TB 12237>        at scbus8 target 0 lun 1 (pass4,nda3)

Jede der Platten hat ein 40GB ufs welches unter /mnt/ufs* gemountet ist.

Als simplen Test, habe ich erstmal 10GB aus /dev/random in ein ramdisk unter /tmp2 geschrieben und diese dann in die jeweilegen Mount-Punkte kopiert:

root@:~ # time cp /tmp2/10G.img /mnt/ufs0/
        2.72 real         0.00 user         2.36 sys
root@:~ # time cp /tmp2/10G.img /mnt/ufs1/
        3.06 real         0.00 user         2.64 sys
root@:~ # time cp /tmp2/10G.img /mnt/ufs2/
        2.93 real         0.00 user         2.57 sys
root@:~ # time cp /tmp2/10G.img /mnt/ufs3/
        2.76 real         0.00 user         2.40 sys

Über 3GB/s ist prima. Check.

Nun kopiere ich die Daten zurück. Einmal cold und dann nochmal hot:

root@:~ # time cp /mnt/ufs0/10G.img /tmp2/
       17.96 real         0.00 user        11.71 sys
root@:~ # time cp /mnt/ufs0/10G.img /tmp2/
        2.49 real         0.00 user         2.49 sys

root@:~ # time cp /mnt/ufs1/10G.img /tmp2/
       88.65 real         0.00 user        11.36 sys
root@:~ # time cp /mnt/ufs1/10G.img /tmp2/
        2.46 real         0.00 user         2.46 sys

root@:~ # time cp /mnt/ufs2/10G.img /tmp2/
       88.58 real         0.00 user        11.68 sys
root@:~ # time cp /mnt/ufs2/10G.img /tmp2/
        2.84 real         0.00 user         2.84 sys

root@:~ # time cp /mnt/ufs3/10G.img /tmp2/
       18.40 real         0.00 user        11.63 sys
root@:~ # time cp /mnt/ufs3/10G.img /tmp2/
        2.83 real         0.00 user         2.83 sys

Die Lexar NVMEs erreichen ca 550MB/s im sequenziellen Lesen. Das ist deutlich weniger als gedacht und beworben. Aber die Crucial erreichen sogar nur nur 110MB/s, das ist ja ungefähr so lahm, wie eine spinning disk. Was ist da los!?

Ich habe die Platten folgendermaßen partitioniert:

gpart create -s gpt  /dev/nda1
gpart add -a 4k -s 1G -t efi nda1
# efi foo
gpart add -a 1m -s 8G -t freebsd-swap -l swap1 nda1
gpart add -a 1m -s 40G -t freebsd-ufs -l reserved1 nda1
newfs /dev/nda1p3
gpart add -a 1m -t freebsd-zfs -l zpool1 nda1

Obige Tests fanden wie gesagt auf dem UFS statt. Es ist noch kein FreeBSD installiert und auch noch kein Zpool eingerichtet (ich bin in der Live-Umgebung).

Habe ich was falsch gemacht? Wie komme ich hier weiter?

Danke für eure Hilfe!

 

[turrican]

ein einzelnes cp mit einem 10GB großen File ist ggf mit ner nvme nicht ganz aussagekräftig

starte mal mehrere cp gleichzeitig, mit z.B. 50 - 100 GB großen Dateien oder mach am Besten einen Run mit 'fio'

 

[mr44er]

Ceph performance — YourcmcWiki

yourcmc.ru

Consumer disks geht die Luft aus, wenn man deren cache sequenziell überschreitet. Wo der bei diesem Modell liegt, weiß ich nicht.

Die meisten disks haben den namespace ab Werk aus Kompatibilitätsgründen auf 512er sectorsize, performen aber besser mit 4k. Wenn deine eine Übersicht hat, ist der Wert relative performance näher an 0 der 'bessere'.

Managing Nvme Namespaces

Manage your nvme device

narasimhan-v.github.io

SOLVED - Intel P4510 NVMe Format 4k

In preparation for a new VM pool on TrueNAS 12-U8.1, I've been going through OpenZFS docs and I came across the section around NVMe low-level formatting LBA size. After a quick scan through the inventory of disks I have, I've discovered only a pair of 1 TB Intel P4510 seem to support LBA 4k...

www.truenas.com

 

[h^2]

ein einzelnes cp mit einem 10GB großen File ist ggf mit ner nvme nicht ganz aussagekräftig

Consumer disks geht die Luft aus, wenn man deren cache sequenziell überschreitet. Wo der bei diesem Modell liegt, weiß ich nicht.

Naja, ich weiß, dass es Cache-Effekte gibt und dass ein einfaches CP nicht total aussagekräftig ist. ABER das stinknormale, serielle Lesen einer Datei im GB Bereich ist schon ein normaler Use-case der auf jeder Desktop-SSD schneller als mit 110MB/s von Statten geht. Und der auch definitiv schneller funktionieren muss in dem Fileserver.

starte mal mehrere cp gleichzeitig, mit z.B. 50 - 100 GB großen Dateien oder mach am Besten einen Run mit 'fio'

Ich habe mal fio angeworfen, mit den Aufrufen, die dieser Kollege benutzt hat:

NFS IOPS Performance on FreeBSD NVMe Storage

Watching too much Linus Tech Tips, I did buy a Gigabyte Server: R272-Z32 with 8x 1.97TB Samsung NVMe Drives. I setup a raidz2 on the 8 drives on a FreeBSD system with a goal of doing sharing over NFS (eventually for VM hosting in XCP-ng). I have a test scenario with the 5 following tests: Test...

forums.servethehome.com

Dies sind die Ergebnisse. Letzte Spalte ist mein "cp nach Ramdisk". Letzte Zeile ist mein Desktop zum Vergleich.

| Disk    | IOPS rand-read | IOPS read  | IOPS write | MB/s read | MB/s write | "cp speed" MB/s |
|---------|---------------:|-----------:|-----------:|----------:|-----------:|----------------:|
| nvd0    |           8650 |     15900  |       4006 |      7717 |       5737 |            572  |
| nvd1    |           5930 |      9935  |       5560 |      7705 |       4039 |            116  |
| nvd2    |           5819 |      9858  |       5548 |      7717 |       4006 |            115  |
| nvd3    |           8447 |     15600  |       3982 |      7653 |       5960 |            565  |
| Desktop |          17800 |    418000  |     211000 |      3772 |        447 |           1932  |

OT: warum kann dit hier ken Markdown?

Also der Benchmark behauptet die Platten würden alle 7700 MB/s lesend erreichen. Das sieht mir angesichts der schlechten cp Performance aber eher nach dem synthetischen Wert aus. Die IOPS sind auch absurd niedrig. Der Desktop hat eine Samsung NVME drin, und ZFS statt UFS.

Die meisten disks haben den namespace ab Werk aus Kompatibilitätsgründen auf 512er sectorsize, performen aber besser mit 4k. Wenn deine eine Übersicht hat, ist der Wert relative performance näher an 0 der 'bessere'.

Danke für den Hinweis! Ich habe das gecheckt, und die Crucial NVMEs bevorzugen tatsächlich 4k (die Lexar jedoch 512). Aber das erklärt die schlechte Performance doch trotzdem nicht, inbesondere da fio auch mit 4k Sektoren gelaufen ist.

Ich richte jetzt testweise einen Zpool ein und benchmarke mal da.

 

[h^2]

So, nun die Zahlen mit ZFS:

| Disk    | IOPS rand-read | IOPS read  | IOPS write | MB/s read | MB/s write | "cp speed" MB/s |
|---------|---------------:|-----------:|-----------:|----------:|-----------:|----------------:|
| nvd0    |          53700 |    795000  |     456000 |      4715 |       5574 |            3459 |
| nvd1    |          53700 |    792000  |     457000 |      2632 |       5022 |             600 |
| nvd2    |          53500 |    794000  |     455000 |      2600 |       4983 |         600-800 |
| nvd3    |          53700 |    796000  |     456000 |      4578 |       5737 |            2925 |

Die sind im großen und ganzen "realistisch", also war oben das Problem nur UFS.

Allerdings sind mir die Zahlen auf den Crucial NVMEs (nvd1 und nvd2) immernoch zu weit von dem entfernt was die Karten eigentlich leisten sollten.

Ich habe dort jetzt auch erfolgreich das LBA format auf 4k geändert – was ein Neuformatieren und Partitionierung erforderlich macht. Groß ändern tun sich die Zahlen aber nicht (ca 5-10% mehr im sequential read benchmark, sonst nichts).

 

[mr44er]

Gibt es vielleicht noch aktuellere firmware oder laufen die heiß, sodass gedrosselt wird?

 

[h^2]

Gibt es vielleicht noch aktuellere firmware oder laufen die heiß, sodass gedrosselt wird?

Temperatur ist in Ordnung und Firmware finde ich keine neuere auf der Herstellerseite.

Ich habe es jetzt nochmal gecheckt. Statt cp nehme ich ein cat /z0/10GB.img > /dev/null um Effekte mit dem RAM und der ramdisk auszuschließen. Das Verhalten ist aber dasselbe wie vorher. Wenn ich jedoch statt der 10GB eine 5GB Datei nehme, dann geht die Performance auf beiden crucials von 600-800MB/s auf 1400-1600MB/s. Bei den Lexar Platten bleibt sie stabil über 2700MB/s.

Das beim Schreiben ein Puffer verwendet wird, der irgendwann voll ist, finde ich logisch, aber warum die Read-Performance nach einer Weile so einbricht, erklärt sich mir nicht. Ist mir aber jetzt auch zu blöde. Ich gebe die Crucials zurück und hole mir nochmal zwei Lexars.

 

[serie300]

Um die Datenrate auszureizen - würde es Sinn machen, es mit dd zu probieren ? Dann ist kein Dateisystem im Spiel.
Also etwa so

dd if=/dev/random of=/dev/nda0 bs=1M count=1000

Mit entpsrechenden Schaltern sollte man bei dd auch den Fortschritt sehen. Ist jetzt nur 'ne Idee

 

[turrican]

ein dd wird vermutlich das selbe Bild wie ein cp erzeugen;
nvme leben ja scheinbar von Parallelität - wenn alle io-queues und die io-depth gut ausgelastet sind; vermutlich erzeugt ein einzelnes cp/dd nicht die mögliche Last;

untersuch doch auch mal, wie die nvme Slots auf dem Board hardwaremäßig angebunden sind, wieviel Lanes jeder Slot abkriegt etc;
nicht, dass das Board nur vollen Speed erreicht, wenn eine nvme gesteckt ist, aber nicht wenn mehrere gesteckt sind - da sich dann irgendwo Bus-Bandbreite aufteilt etc

 

[h^2]

untersuch doch auch mal, wie die nvme Slots auf dem Board hardwaremäßig angebunden sind, wieviel Lanes jeder Slot abkriegt etc;

Ich habe extra darauf geachtet, dass alle NVME slots parallel mit jeweils 4x versorgt werden.

Aber ich habe gestern noch die Crucials zurückgeschickt und mir noch zwei Lexars bestellt. Wenn die da sind, werde ich nochmal vergleichen!

 

[turrican]

du könntest (besser: hättest können, hast ja schon zurückgeschickt) auch noch ein aktuelles Linux von nem Stick booten und die Tests mit cp und ggf dd nochmal machen, auch mit fio, mit ioengine "libaio" (--ioengine=libaio);
wäre interessant, ob diese Werte von denen von FreeBSD abweichen, bei unverändertem Hardware-Setup;

Hier noch ein ähnlicher Versuch mit Statement zu cp und dd;

 

[double-p]

also bei so drastischen unterschieden, mit dem gegebenem setup (2x zwei nvme/wechselnd (interleave etc)) waer ich auch erstmal davon ausgegangen, dass das produkt einfach kagge ist (soll's geben! ) - und man sich in den mess-setup-feinheiten nur mehr Zeit verlieren kann.

Bin gespannt wie es mit 4x der gleichen Platte aussieht (hinsichtlich der Moeglichkeit von turrican)

 

[h^2]

Sie sollen heute noch ankommen angeblich. Ich werde berichten!

 

[h^2]

So, nun die Ergebnisse mit den neuen Platten (1 und 2):

| Disk    | IOPS rand-read | IOPS read  | IOPS write | MB/s read | MB/s write | "cp speed" MB/s |
|---------|---------------:|-----------:|-----------:|----------:|-----------:|----------------:|
| nvd0    |          50000 |    822000  |     470000 |      4378 |       5766 |            2732 |
| nvd1    |          54900 |    803000  |     461000 |      5138 |       5695 |            2724 |
| nvd2    |          54900 |    806000  |     459000 |      5148 |       5769 |            2717 |
| nvd3    |          49500 |    816000  |     470000 |      4387 |       5851 |            2732 |

Interessanterweise sind die neuen sogar ein kleines bisschen schneller im fio seq-read-benchmark. Das ist aber alles nicht zentral, solange wir uns beim Kopieren im GB-Bereich bewegen, ist alles gut. Ich habe momentan kein Linux zur Hand und will mit den anderen Sachen vorankommen, aber ich werde am Ende vielleicht nochmal Benchmarks machen, auch mit Linux.

Fazit: keine Crucial NVMEs kaufen, denn fürs gleiche Geld (bzw. sogar weniger) kriegt man von Lexar besseres. Fun fact: die Lexar NVME haben sogar 4096GB während die Crucial 4000GB hatten. Ich traue mich wegen Erweiterbarkeit des Pools allerdings nicht den Platz ganz auszuschöpfen. Wer weiß ob ich in Zukunft nochmal eine NVME kriege die auch echte TiB hat, das ist ja insgesamt eher selten.

 

[foxit]

Du vergleichst hier aber QLC und TLC SSDs. QLC-SSDs in der Regel weniger zuverlässig als TLC (behaupte ich jetzt einfach mal). Auch glaube ich, sind das nicht die gleichen Generationen von SSDs.

 

[h^2]

Du vergleichst hier aber QLC und TLC SSDs. QLC-SSDs in der Regel weniger zuverlässig als TLC (behaupte ich jetzt einfach mal).

Ja, naja, ich vergleiche zwei 4TB NVMEs im Preisbereich ~200€! Aber ja, die Lexars sind eine der wenigen TLC Platten in dem Bereich. Noch ein Grund mehr die zu nehmen.

uch glaube ich, sind das nicht die gleichen Generationen von SSDs.

Es sind beides NVMEs die für PCIe 4.0 x4 ausgelegt sind.