ESXi all in one NFS Speicher performance mit PCIe SSDs

[mmoolifu]

Da habe ich mal ne Frage zu diesem Setup:

zpool:
* mirror mit 2 ssds, jeweils in PCIe 3 eingesteckt, (je 1x Transcend MTE250H und MTE220S ), Kompression mit LZ4
* arc und slog auf demselben Optane (56GB oder so, komisches Modell) auch in PCIe 3 eingesteckt
* all diese Geräte per pass-through an VM weitergeleitet
* diese Speicher VM hat nur ca. 4GB RAM, NICs sind vmxnet3
* nfs shares von dieser VM in ESXi gemountet (noch nfsv3, sollte aber v4 werden)
* separate vSwitch/Portgruppe/vmkNIC im ESXi für das interne 'Speicher'-LAN, MTU mal auf 5000
* ESXi ist noch Version 6.5

Nun läuft auf diesem Speicher eine Windows VM, und es wird ne paar GB große Datei kopiert (von/zu demselben Laufwerk):
Zurzeit scheint mir die Schreibgeschwindigkeit 'am langsamsten'/(Tiefpunkt der angezeigt wird) bei ca. 250MB/s zu landen - müsste es nicht schneller sein können?
An welchen Stellschrauben kann man die Geschwindigkeit tunen?

Ein Punkt, den ich vorhin gefunden habe, und den man wohl erst am ESXi 7 einstellen kann, ist das Deaktivieren der nfs Delayed ACK time von 100ms.
Umstellen auf nfsv4 will ich noch machen.

viele grüße

 

[asche77]

* diese Speicher VM hat nur ca. 4GB RAM

Hier liegt der größte Fehler. MEHR RAM!!!

* arc und slog auf demselben Optane (56GB oder so, komisches Modell) auch in PCIe 3 eingesteckt

Abschaffen. Erstens ist das [edit: vermutlich] eine lahme Optane, zweitens bringt L2ARC oft nichts, drittens schadet Dir das bei so wenig RAM viel mehr als es nützt. [Edit:] Viertens behindern sich l2arc und slog gegenseitig, da sie beide Schreiblast erzeugen.

 

[Potz]

Ich schließe mich an, dass 4GB RAM ziemlich sicher die allgemeine Performance limitieren und der L2ARC überflüssig ist, aber für dein beschriebenes Szenario sollte beides egal sein.
Was das ZIL/slog angeht, sehe ich schon eher ein Limit bei der Optane. Falls die Schreibzugriffe in deinem Szenario synchron ablaufen (ich weiß nicht wie du es konfiguriert hast und wie dein Software-Stack sich da verhält), dürfte es mit der kleinen "lahmen" Optane einen Flaschenhals geben. Ein bisschen schneller hätte ich es schon noch erwartet, aber der ganze Aufbau ist und bleibt auf der Softwareseite schon relativ ineffizient, so dass das passen könnte.

 

[gea]

Man muß unterscheiden was besser konfiguriert werden kann and was geändert werden muss.

Das größte Problem dürfte RAM sein. Selbst ein minimalistisches Solaris/Illumos das für ein ZFS System die effektivste Speicherverarbeitung hat, ist mit 4 GB am unteren Limit. BSD oder Linux basierte Systeme sollten spürbar mehr RAM haben. Ein L2Arc kann bei sowenig RAM zwar dafür sorgen dass alles stabiler läuft, kann aber Performance kaum verbessern.

Ich würde:
auf der Optane einen Pool anlegen (kein L2Arc) und Performance mit sync=disabled testen. Damit ergibt sich die bestmögliche Performance mit 4GB RAM. Dann gleiches mit den SSD um zu sehen um wieviel schlechter die SSD sind (mit NFS3, eher schneller als NFS4). Diesen Test mit sync=always wiederholen.

Dann mehr RAM geben, idealerweise > 8GB und Tests wiederholen, wenn RAM vorhanden auch mehr testen.
Da auf den anderen SSD wiederholen um zu sehen wieviel schlechter die sind als eine Optane. Die Optane 800-64GB ist übrigens relativ schnell, lahm sind die kleineren 16/32GB Modelle.

Wenn man dann weiß was gehen könnte:
Für sicheren VM Betrieb braucht man unbedingt sync write und eigentlich SSD/NVMe mit Powerloss Protection. Mit einem NVMe Pool ist ein separates Slog kaum hilfreich auch wenn selbst die billigeren Optane meist unkritischer sind als übliche Desktop NVMe/SSD. Ein Slog mit Powerloss Protection bei einem SSD Pool ohne PLP berbessert die Sicherheit nur minimal.

 

[mmoolifu]

oha, vielen Dank für die Vorschläge und Ratschläge! Da habe ich ja noch ziemlich viel zum Ausprobieren...📝
Mein heutiger kleiner Test war erstmal nen simplen Benchmark zu machen: Archiv.zip (6,1GB) 10x kopieren, auf derselben Platte, innerhalb der VM.

Folgende Resultate gab es:
Hardware:
HP Z420, Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz (alte Kiste)
ESXi 6.5 HP Image

sudo zpool list -vP

NAME                                                                SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
pool1                                                              1.82T   532G  1.30T        -         -    14%    28%  1.01x    ONLINE  -
  mirror                                                           1.82T   532G  1.30T        -         -    14%  28.6%      -    ONLINE
    /dev/disk/by-id/nvme-TS2TMTE220S_##                                -      -      -        -         -      -      -      -    ONLINE
    /dev/disk/by-id/nvme-TS2TMTE250H_##                                -      -      -        -         -      -      -      -    ONLINE
logs                                                                   -      -      -        -         -      -      -      -  -
  /dev/disk/by-id/nvme-INTEL_SSDPEK1W060GA_##-part1                   2G   186M  1.82G        -         -     0%  9.09%      -    ONLINE
cache                                                                  -      -      -        -         -      -      -      -  -
  /dev/disk/by-id/nvme-INTEL_SSDPEK1W060GA_##-part2                51.6G  39.9G  11.7G        -         -     0%  77.3%      -    ONLINE

Benchmark: auf E: 10x Bundle.zip (6,1GB) kopieren, mehrere Durchgänge
* 403.33s total
* 414.07s total
* 432.62s total
* 444.69s total
* 437.48s total
* 422.67s total
* 431.49s total
Benchmark dito, Änderung: MTU 9000 statt 5000 / ohne Reboot!
* 437.60s total
Benchmark dito, nach ESXi Host reboot
* 384.21s total
* 447.99s total
* 410.60s total
Benchmark dito, nach sudo zpool remove pool1 nvme-INTEL_SSDPEK1W060GA_##-part1
* 857.64s total
* 857.64s total hä!?
* 864.56s total (zugucken per `sudo zpool iostat -vly 1` bringt zeitweise erstaunlich kleine zweistellige Werte )
Benchmark dito, nach sudo zpool remove pool1 nvme-INTEL_SSDPEK1W060GA_##-part2
* 856.01s total
Benchmark dito, nach sudo zpool add pool1 log nvme-INTEL_SSDPEK1W060GA_##-part1
* 430.78s total

erste Interpretation ist, dass das Optane Log doch etwas hilft - ist ja komisch. Mehr RAM wird als nächstes probiert 👍

viele grüße

 

[gea]

Ich würde vorher noch testen was maximal möglich wäre (mit einem Pool auf der Optane und sync=disabled vs always, kein L2Arc, kein Slog).
Dann kann man besser abschätzen um wieviel besser/schlechter eine spezielle Konfiguration ist.

ps
Die besseren Werte mit Slog lassen vermuten dass die Transcend nicht so toll ist.

Slog schützt den Inhalt des rambasierten Schreibcaches
2GB ist etwas knapp. Die Daumenregel sagt 2 x Ram Schreibcache also ab ca 10GB.
Bei sehr schnellen NVMe ist ein separates Logedvice kaum hilfreich.
Da es mit 4GB Gesamtram aber kaum Schreibcache gibt ist 2 GB Slog hier ok, nicht aber mit mehr RAM.

L2Arc braucht zur Verwaltung etwas vom bereits knappen RAM
Daumenregel: L2Arc max 5 x RAM

RAM
Ein 64bit OS braucht heutzutage mindestens ca 3GB RAM. ZFS braucht auch etwas für einen minimalen Cache
sonst muss gleich auf Platte geswappt werden. Für ein Solaris basiertes mini Storage OS wie OmniOS bei dem
OS RAM=ZFS RAM ist, würde ich minimum 1 GB hinzurechnen, bei BSD oder Linux eher 3 GB.

Erst der RAM darüber wird tatsächlich als Lese/Schreibcache beschleunigend.

 

[mmoolifu]

Vielen Dank für die fundierten Ratschläge! Heute bin ich nur zu wenigen weiteren Analyse-Schritten gekommen:

Benchmark dito, nach +RAM: nun 6GB RAM
* 397.50s total
* 382.15s total
Benchmark dito, nach +RAM: nun 8GB RAM
* 363.24s total -> 173MiB/s
* 383.57s total -> 164MiB/s
* 414.64s total -> 152MiB/s
Benchmark dito, nach sudo zfs set sync=always pool1
* 420.47s total -> 150MiB/s
Benchmark dito, nach sudo zfs set sync=disabled pool1
* 331.04s total -> 190MiB/s

sudo zpool create -o ashift=12 poolp /dev/nvme0n1p1
...
sudo zpool list -vP
NAME                                                    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
poolp                                                  54.5G   456K  54.5G        -         -     0%     0%  1.00x    ONLINE  -
  /dev/nvme0n1p1                                       54.5G   456K  54.5G        -         -     0%  0.00%      -    ONLINE

Benchmark im Terminal der Speicher VM: 7x bench.zip (6,618,175,818 bytes = 6312MiB )*7= 44184MiB kopieren (nicht mehr Platz vorhanden) (also sync = standard zu Beginn)
cd /poolp/bench
set src 'bench.zip' && cp $src b01 && cp $src b02 && cp $src b03 && cp $src b04 && cp $src b05 && cp $src b06 && cp $src b07 && rm b0*
* 01:47 = 107s -> 412MiB/s (plausibel per iostat beim Zugucken)
* 01:47 dito
Benchmark dito, nach sudo zfs set sync=always poolp
* 02:41 = 161s -> 274MiB/s
* 02:42 = 162s -> 272MiB/s
Benchmark dito, nach sudo zfs set sync=disabled poolp
* 01:43 = 103s -> 428MiB/s
* 01:41 = 101s -> 437MiB/s
Benchmark dito, nach sudo zfs set sync=standard poolp / nur so um festzustellen, dass es in sich stimmig ist
* 01:42 = 102s -> 433MiB/s
Benchmark dito in VM, auf virtueller HDD auf poolp - hier nur noch Platz für 5 Kopien (31560MiB)
* 137.95s total -> 228MiB/s (plausibel per iostat beim Zugucken)
* 146.74s total -> 215MiB/s

fehlt noch: dito mit sync = disabled /always

Interpretation:
Das deutet erstmal darauf hin, dass die Hardware bzgl. Optane ungefähr so läuft wie sie soll, denn, laut Datenblatt kann der ca. 640MB/s (edit) schreiben (vermutlich nicht MiB🤦) und gleichzeitig muss ja auch noch gelesen werden....
Dass in der VM dann etwas mehr als die Hälfte ankommt, ist natürlich etwas dürftig... da muss wohl der Hund begraben liegen. Aber vorher werde ich die Performance auf den Transcend SSDs in der Speicher VM noch angucken...
(edit Davon abgesehen macht es wohl doch Sinn, das Ding neu aufzusetzen - bisher war der pool1 nämlich mit HDDs, und es wäre gut, alle Parameter wie Sektorgrößen und so aufeinander abzustimmen..
... wird fortgesetzt werden...

 

[asche77]

Du könntest auch ashift=13 probieren - zumindest für Samsung (SATA) SSDs soll das besser sein, da die wohl eine interne Blockgröße von 8MB haben statt 4MB. Wie das bei den Transcend NVME aussieht: Keine Ahnung. Zu hohe ashift schadet aber kaum, zu niedrige schon.

 

[gea]

Ich habe gerade den Speicherverbrauch meiner AiO Test Storage VM kontrolliert. Meine OmniOS VM hat auch 4GB RAM, davon sind aber nach dem Booten (Arc Cache noch nicht gefüllt) immer noch ca 2,7GB frei obwohl iSCSI, NFS und SMB (alles Solaris eigene Dienste die Teil des Betriebssystems sind) aktiviert sind. Extrem effizizient trotz ihrer Leistungsfähigkeit und das für ein 64bit Server Unix. Hier sieht man halt wie resourcenschonend Solaris ist auch weil die ZFS Speicherverwaltung immer noch auf Solaris basiert. Damit ist OS RAM=ZFS RAM,

Für wenige Nutzer und schnelle Platten ist das voll ausreichend, bei langsameren Platten ist der Schreib/ Lesecache etwas knapp.

 

[mmoolifu]

na das ist ja sehr interessant. Dann steht mehr beim RAM variieren jetzt auch noch aufm Plan.
Heute bin ich nicht weit gekommen:

Benchmark dito, nach sudo zfs set sync=always poolp
* 142.00s total -> 222MiB/s
* 143.55s total -> 219MiB/s
Benchmark dito, nach sudo zfs set sync=disabled poolp
* 116.53s total -> 270MiB/s
* 115.51s total -> 273MiB/s
Benchmark dito, in VM (übrigens Win10, virtuelle HDD ist NTFS), 4k Sektoren, nochmal voll formatiert (war vorher wohl quick format)
* 120.03s total -> 263MiB/s
* 118.79s total -> 265MiB/s
Benchmark dito, nach sudo zfs set sync=standard poolp / nur so um festzustellen, dass es in sich stimmig ist
* 147.92s total -> 213MiB/s
* 147.23s total -> 214MiB/s
Benchmark dito in VM, nach sudo zfs set atime=off poolp
* 146.07s total -> 216MiB/s
* 149.17s total -> 211MiB/s
* 147.35s total -> 214MiB/s
Benchmark dito in VM, nach sudo zfs set compression=lz4 poolp und dann erneutem hinkopieren der Quelldatei in der VM
* 148.82s total -> 212MiB/s (plausibel per iostat beim Zugucken, schwankt dabei etwas mehr als vorher, rein subjektiv)
* 148.82s total (!) -> 212MiB/s
nach ESXi vmk1 entfernen von 'management' bei dessen Services, Host reboot
* 141.44s total -> 223MiB/s (generell scheint beobachtbar, dass die Kiste etwas zügiger ist direkt nach booten)
* 149.86s total -> 210MiB/s
* 147.60s total -> 213MiB/s
Benchmark dito in VM, nach sudo zfs set sharenfs=rw=xxx,insecure,all_squash,async poolp und reboot speicher VM
* 121.91s total -> 259MiB/s (interessant, dass das doch etwas langsamer ist als bei zfs sync=disabled)
* 121.61s total -> 259MiB/s
* 120.90s total -> 261MiB/s
Benchmark dito in VM, nach sudo zfs set sharenfs=rw=xxx,insecure,all_squash,no_subtree_check poolp und reboot speicher VM
* 138.83s total -> 227MiB/s
* 140.25s total -> 225MiB/s
* 148.48s total -> 213MiB/s
* 147.10s total -> 214MiB/s
Benchmark dito in VM, nach sudo zfs set sharenfs=rw=xxx,insecure,all_squash,no_subtree_check,no_wdelay poolp und reboot speicher VM
* 147.86s total -> 213MiB/s
* 147.50s total -> 214MiB/s
* 149.98s total -> 210MiB/s
* 146.17s total -> 216MiB/s

Benchmark im terminal: 7x bench.zip nun noch auf pool1 (der mit den beiden SSDs, dort ist compression=lz4)
cd /pool1/bench
set src 'bench.zip' && cp $src b01 && cp $src b02 && cp $src b03 && cp $src b04 && cp $src b05 && cp $src b06 && cp $src b07 && rm b0*
* 1:22 = 82s -> 538MiB/s
* 1:17 = 77s -> 573MiB/s
* 1:15 = 75s -> 589MiB/s
* 1:20 = 80s -> 552MiB/s
Benchmark dito, nach sudo zfs set sync=always pool1
* 10:27 = 627s -> 70MiB/s (beim Zugucken per iostat scheint es mir so, dass je Datei erstmal der SSD Cache verwendet wird, dann bricht die Geschwindigkeit total ein auf unter 10MiB/s, sehr interessant!)
Benchmark dito, nach sudo zfs set sync=disabled pool1
* 1:14 = 74s -> 597MiB/s
Benchmark dito, nach sudo zfs set sync=standard pool1
* 1:18 = 78s -> 566MiB/s

nebenbei gibts einiges perspektivisch einzustellen: NFS mit RDMA wäre wohl hipp (wobei ich mich frage, ob ESXi das als Client überhaupt könnte), NFSv4 sowieso, und zum Thema NVMe ggf auch noch etwas...
ashift 13 vs 12

Chapter 4. Exporting NFS shares Red Hat Enterprise Linux 8 | Red Hat Customer Portal

Access Red Hat’s knowledge, guidance, and support through your subscription.

access.redhat.com

Best Practices For Running NFS with VMware vSphere | VMware

This guide provides an overview of the considerations, best practices for deployment of VMware vSphere on NFS based storage and troubleshooting tips and tricks.

core.vmware.com

How to increase the number of threads created by the NFS daemon in RHEL 4, 5, 6, 7 and 8? - Red Hat Customer Portal

In case of a NFS server with a high load, it may be advisable to increase the number of the threads created during the nfsd server start up. How to increase the threads created by nfs daemon in Red Hat Enterprise Linux? RPCNFSDCOUNT nfs thread count / nfsd thread count

access.redhat.com

Doubling Network File System Performance with RDMA-Enabled Networking | NVIDIA Technical Blog

Network File System (NFS) is a ubiquitous component of most modern clusters. It was initially designed as a work-group filesystem, making a central file store available to and shared among several…

developer.nvidia.com

Binding VMware ESXi NFS traffic to custom vSphere TCP/IP stack - nicoblidi.com

Binding VMware ESXi NFS traffic to custom vSphere TCP/IP stack when your NFS server and your ESXi hosts don't belong to the same VLAN/subnet

nicoblidi.com

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

Das wird ne Weile dauern...

 

[gea]

Ein paar Grundsätze die ich immer beachte:
-Compress immer ausschalten, man will ja nicht wissen wie gut spezielle Daten kompimiert werden können, sondern wie schnell der Pool ist
-Tests immer lokal machen (Console Tools). Wenn man wissen will wieviel davon bei SMB/NFS ankommt so ist das eine Extra Testreihe
- Sync=default bedeutet dass das schreibende Programm entscheidet, Bei ESXi+NFS ist das sync enabled
- Sync wirkt nur beim Schreiben, nicht beim Lesen.
Je größer der Unterschied beim Schreiben sync vs async, desto schlechter die SSD. Bei Festplatten kann das 150MB/s vs 10 MB/s sein.
- Idealerweise testet man sync write vs async write sequentiell und mit random io, Write Werte sind wichtiger als Read.
Read sollte ähnlich sein, bessere readwerte liegen am Cache. Wichtig ist noch single user/stream vs multi.

Bei (Desktop) SSD bricht die Schreibrate oft nach kurzer Zeit ein vor allem beim gleichzeitigen Lesen. Das kann man aber nur mit speziellen Tests messen.

z.B. https://www.napp-it.org/doc/downloads/optane_slog_pool_performane.pdf

 

[Potz]

Bei (Desktop) SSD bricht die Schreibrate oft nach kurzer Zeit ein vor allem beim gleichzeitigen Lesen. Das kann man aber nur mit speziellen Tests messen.

Und falls man das bei einer SSD ohne PLP mit synchronen Schreibzugriffen gemessen hat, weiß man, dass die SSD "lügt". Die Daten sind dann im Zweifel einfach futsch. Eine SSD ohne PLP ist unfassbar langsam bei synchronen Schreibzugriffen (zweistellig MB/s)

 

[gea]

Lügen ist ein hartes Wort.
Es wird lediglich verschwiegen dass eine gute Schreibperformance nur mit Hilfe eines RAM Schreibcaches erreicht wird, dessen Inhalt beim Absturz verloren ist. Nur teure SSD sichern das ab oder haben wie Intel Optane gar keinen Cache und sind dennoch schneller als alle Flash basierten Platten. Einen Einbruch nach einiger Zeit vor allem bei mixed read/write haben bis auf Optane alle Flash basierten Laufwerke. Das liegt an der Block/Page orientierten Arbeitsweise bei dem nur blockweise gelöscht werden kann während Optane auf jede Zelle/Datenblock direkt lesend/schreibend zugreifen kann wie es ansonst nur bei RAM und mechanischen Platten geht.

Selbst wenn Intel da bei einigen Modellen wie der Optane 900 keine powerloss protection angibt, kann man ziemlich sicher sein dass ein Stromausfall problemlos verdaut wird.

 

[Potz]

Lügen ist meiner Meinung nach das passende Wort, wenn man einen synchronen Schreibzugriff verlangt, die SSD das ACK aber schon gibt, bevor die Daten wirklich geschrieben sind. Macht nicht jede SSD ohne PLP mit DRAM Cache so. Die die es tun, lügen meiner Meinung nach. Die anderen sind halt unfassbar langsam.
Zum Thema "Performanceeinbruch bei längerem Schreiben" möchte ich ergänzen, dass für Server gedachte SSDs mit PLP nicht ohne Grund bei der Schreibperformance laut Datenblatt gegenüber Consumer-Ware eher schlecht dastehen. Das was bei den "professionellen" Laufwerken im Datenblatt steht erzielt die Platte dauerhaft (In der Realität hat man natürlich nicht immer das ideale Szenario für das der Wert im Datenblatt ermittelt wurde).

 

[mmoolifu]

also ich glaube, ich habe da in der VM irgendwie nen Knoten drin. In der Zwischenzeit habe ich:
* ESXi 7.0U3 neu, blank, installiert
* Optane mit neuer Firmware aktualisiert
* eine Windows 10 VM zum Testen der Transcend SSDs neu erstellt.

Im Ergebnis werden die SSDs dort angezeigt, als ob sie an PCIe Gen2 hängen:

Andererseits scheinen sie aber laut CrystalDisk Benchmark so schnell zu sein, wie im Datenblatt:
(Bild habe ich vergessen, ergänze ich noch)./ ergänzt:

Wenn ich auf der Linux VM (nun neue virtuelle HDD: Almalinux 9.1) einen 'Benchmark' mit dd durchlaufen lasse nach dem Muster von
https://github.com/tdg5/blog/blob/master/_includes/scripts/dd_obs_test.sh
(erweitert um ein paar Schleifen für Dateigrößen 32MiB/6,25GiB , ashift12/13 und vdevs, sync immer 'always'), dann komme ich aber auf ziemlich kleine Werte, auch bei der kleinen Datei - zumindest da sollte es schneller gehen dank SLC Cache bzw. RAM der SSDs, würde ich denken.
(Hierbei wird vor jedem Durchlauf der Kernel Cache gelöscht via ' [ $EUID -eq 0 ] && [ -e /proc/sys/vm/drop_caches ] && echo 3 > /proc/sys/vm/drop_caches ', damit es nicht zu Verfälschungen durch den Cache kommt.)

und das auch, wenn die SSD mit xfs formatiert ist (das legt nahe, dass es nicht an zfsonlinux liegt, sondern an der VM oder ESXi im Allgemeinen):

Vielleicht hinkt der Vergleich aber auch gewaltig, weil der CrystalDisk Benchmark unter Windows möglicherweise keine sync writes macht...

Betreffend der Hardware sind beide SSDs aber in einem PCIe Gen 3 x16 Slot (mit noname LOGILINK PC0084 PCIe zu M.2 PCIe SSD Adapter), in einem HP Z420 (der ist natürlich schon älter, von 2012 glaube ich).
Nur die Optane SSD steckt an einem Gen 3 x8 Port, ebenso mit dem ollen Adapter.
Die anderen Steckplätze am Board sind PCIe Gen 2.

Auf echter Hardware direkt scheint der dd-'Benchmark' deutlich größere Zahlen auszuspucken, aber diese beiden SSDs habe ich damit noch nicht getestet. Das wäre wohl einer der nächsten Schritte, die zu testen auf derselben und anderer echter Hardware.

Eigentlich dachte ich, nach dem Neu-aufsetzen müsste alles schneller sein, und hatte noch einige Schleifen für das Ausprobieren einiger zfs Kernel-Parameter ins Skript gebastelt.
(via https://github.com/openzfs/zfs/issues/8381 (unten) und https://zfsonlinux.topicbox.com/groups/zfs-discuss/T5122ffd3e191f75f )
...Aber das macht hier noch keinen Sinn...
Gibt es irgendetwas, das falsch konfiguriert sein könnte, sodass die PCIe-Slots zu langsam laufen?
Im BIOS ist dort zumindest PCIe Gen3 eingestellt - falls man wollte, könnte man auch auf Gen2 oder 1 limitieren.
In VMWare habe ich aber nichts gefunden, vielleicht gibt es irgendeine Begrenzung, die mir gar nicht klar ist?

 

[Potz]

Ich habe leider keine Ahnung, welche Performance du in einer VM erwarten kannst, aber um das Thema mit den synchronen Schreibzugriffen zu testen, könntest du dir fio als Benchmark-Tool anschauen. Du kannst hier auswählen, ob du sync oder async möchtest.

 

[mmoolifu]

Es ist wie befürchtet:
* booten der VM auf der Hardware direkt: hat natürlich nicht geklappt, also
* booten der Almalinux 9.1 LiveCD per USB: schnelle Werte im 'dd'-'Benchmark':

* booten derselben Almalinux LiveCD in einer neuen VM (also 28 statt 32GB RAM): langsame Werte im 'dd'-'Benchmark' - wie die schon bekannten Werte, deshalb kein neues Bild davon.

Ich habe ein bisschen kreuz und quer durchs Internet gesucht, aber nicht so direkt vergleichbare Probleme gefunden. Meist war das 'langsame' entweder noch viel langsamer oder nur wenige Prozent langsamer als die Hardware-Performance. Verschiedene Anpassungen/Ergänzungen der Einstellungen zum passthrough haben auch keine Änderung gebracht...
Das Einzige, was mich stutzig macht, sind die großen Zahlen in der Windows VM. Aber direkt vergleichbar sind sie ja trotz allem nicht... Ich würde mal versuchen, diesen Benchmark unter Linux nachzustellen....

 

[mmoolifu]

also letztendlich scheint sich herauszukristallisieren, dass das hier eher ein Fall von Halbwissen in Kombination mit DAU-Aspekten meinerseits ist...
Besten Dank für den Hinweis auf fio! Es gibt ja auch KDiskMark, das fio benutzt, und somit hat man schnell ein paar Presets, um Zahlen auf den Bildschirm zu zaubern....

Wenn ich die SSD mit ext4 formatiert habe, dann sind die Zahlen ganz gut:

Ist sie mit ZFS formatiert, machen die drei Möglichkeiten zu sync einen großen Unterschied - da habe ich direkt ne kleinere Datei zum Testen gemacht, weil es so ewig gedauert hatte...

Da ich die schreibe-Tests mit dd ja nur mit sync=always durchgeführt hatte, war das kaum mit anderen Zahlen zu vergleichen...
Aber eine ungefähre Reihenfolge lässt sich auch von den dd-Tests ableiten, finde ich.
Am liebsten würde ich jetzt fio statt dd in die Test-Schleife einbauen, aber um das zu tun, müsste ich noch mehr zu den CLI Parametern und so lesen... (csv-Ausgabe hat echt viele Spalten) es muss ja auch ne sinnvolle Auswertung herauskommen.
Was mich vom dd-Test noch etwas verwundert ist, dass es mit dem Optane als Log nicht so gut abschneidet bzgl. Schreib-Geschwindigkeit (siehe Bild im Anhang) - (aber ich hatte ja nur sync=always und damit ein paar Schleifen gespart).
Die beste Geschwindigkeit beim Mirror gibts bei ashift 12 und 32MiB Blockgröße bei der großen Datei (oder 4MiB @kleine Datei) - aber das kann man doch schlecht als recordsize nehmen...

Momentan tendiere ich dazu, die HDDS der VMs mit 8k zu formatieren, das oder ein Vielfaches als recordsize zu nehmen, und sync=standard zu nehmen, NFS vielleicht async mounten/freigeben. Es ist eher eine Entwicklungskiste, und wenn da der Strom ausfällt, dann verstehe ich es so, ist zwar mehr verloren als wenn ich komplett sync writes gemacht hätte - aber der Strom hätte ja auch ein paar Sekunden früher ausfallen können mit dem gleichen Ergebnis mit sync writes....

 

[Potz]

und wenn da der Strom ausfällt, dann verstehe ich es so, ist zwar mehr verloren als wenn ich komplett sync writes gemacht hätte - aber der Strom hätte ja auch ein paar Sekunden früher ausfallen können mit dem gleichen Ergebnis mit sync writes....

Hmm, nee so einfach ist das nicht. Der Unterschied ist, dass bei sync der schreibende weiß, dass geschrieben wurde und ohne halt nicht. Problematisch ist nicht unbedingt, dass etwas verloren geht (kann man letztlich nicht verhindern), sondern dass Dinge verloren gehen, von denen man dachte man hätte sie geschrieben. Das kann zu Inkonsistenzen führen. Jetzt ist es leider nicht so, dass jegliche Software perfekt geschrieben wäre und sauber mit synchronen Schreibzugriffen umgeht. Am weitesten vorne (Probleme bleiben trotzem) ist man hier für Software-Stacks mit vielen Layern, wie bei VMs vmtl. mit sync=always, weil somit Andendungen "ausgebremst" werden, bei denen der Entwickler vielleicht vergessen hat, dass er eigentlich hätte an genau dieser Stelle synchron schreiben müssen. Wie realistisch dieses Szenario ist, weiß ich allerdings nicht. Bei sync=standard überlässt man allen "Kunden" selbst zu entscheiden, ob die Software hier einen synchronen Schreibzugriff braucht oder nicht. Da hier allerdings etliche Schichten Software noch über dem ZFS arbeiten, weiß man nie so genau, was da eigentlich los ist.
Zusammengefasst: Auch bei mir nur ungesundes Halbwissen, aber zumindest die Einsicht, dass die Sache sehr komplex ist. Es ist nicht wirklich einfach abzuwägen, wo die beste Balance zwischen Datenintegrität und Geschwindigkeit ist. Mit Optane (ich habe eine P4801X 200GB im NAS) kann man sich schon sehr viel Performance bei sync=always erkaufen. Ich bin damit zufrieden und gehe das Risiko ein, dass mein Dateisystem kaputt ist, wenn Stromausfall und Versagen der Optane zeitlich zusammenfallen.

 

[gea]

Sehe ich genauso. Datenverluste oder korrupte Daten sind nicht schlimm und kaum vermeidbar wenn etwas abstürzt. Viel schlimmer sind korrupte Daten von denen man nichts weiß. Ein Absturz bei Schreiben ohne sync kann auch bei ZFS eben dazu führen dass ein Dateisystem einer VM oder ohne ZFS ein Raid inkonsistent ist. Bei einem Mirror z.B. dass ein Spiegel Daten geschrieben hat und der andere noch nicht. Es gibt eben Parallität nur in der analogen Welt. Das darf nicht passieren und sync write sorgt dann dafür dass bestätigte Schreibvorgänge (nur darum dreht es sich) tatsächlich auf dem Pool sind - spätestens nach dem nächsten Reboot.

Schreiben ohne sync ist für ZFS ok und bei einem SMB Filer allenfalls ein kleines Problem. Nur bei kleinen Dateien ist in einem kurzen Zeitfenster eine Situation denkbar wo sync=always etwas verbessert. Hat man aber VMs oder Datenbanken auf dem Storage ist sync write unabdingbar,

 

[mmoolifu]

wer viel misst, misst viel und auch viel Misst..
Mit fio kommen natürlich andere Zahlen zustande, zumal nun auch zu 75% im Benchmark gelesen wird:
FIO_RESULT=$(fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=$BLOCK_SIZE --iodepth=64 --readwrite=randrw --rwmixread=75 --sync=sync --numjobs=5 --group_reporting --size="$TEST_FILE_SIZE" --filename="/$ZPOOL_NAME/$TEST_FILE" --output-format=terse)

Vor allem bei kleinen Dateigrößen könnte man auch gerne mehr als 5 Durchläufe machen.... vielleicht passe ich das noch an...
Je nach Spalte, nach der sortiert wird, ist diese oder jene Konfiguration vorne:

Nach Lesen (Mittelwert):

Nach Schreiben (Mittelwert) - ab Zeile 8 erst unterscheidet sich die Reihenfolge:

Nach Schreiben KB/s: (da ist mir noch nicht klar, wieso viele weitere Spalten keine Zahlen haben...)

Dass die Transcend SSDs einzeln schnell sind, war abzusehen. Dass es aber nahezu aufs Gleiche rauskommt, ob ashift 12 oder 13, hätte ich nicht gedacht. Interessant ist auch, dass es mit cache und log besser abschneidet als nur mit log (die sind jeweils Partitionen auf dem einzelnen Optane (die Spalte ist etwas abgeschnitten)). - wobei das wohl an der Aufteilung auf Lesen/Schreiben liegen wird...

Da gerade openzfs 2.1.10 erschienen ist, und die Testläufe mit 2.1.9 waren, mache ich sie jetzt nochmal mit der aktuellen Version. Mal sehen, es soll bzgl. mancher Wartezeiten Verbesserungen geben, das könnte sich bei nvme auswirken...

 

[mmoolifu]

also jetzt habe ich mir endgültig ein Rätsel zusammengebastelt:
* SSDs ersetzt durch 2x Micron 7400 3,84TB, mit 4k LBA formatiert
* Benchmark per Skript mit zfs-Parametern per Tabelle
* wie es aussieht optimiere ich wohl in Richtung 8k, weil die Festplatten der VMs mit dieser Clustergröße zum größten Teil formatiert sind/sein werden.

Erwartung: müsste ja reproduzierbare Ergebnisse liefern. Aber irgendwo ist noch ein Osterei versteckt.....
Hier das Skript: https://gist.github.com/mmoole/5186f9fc0d5c2f7641880c5ef9384020
und hier ein Ausschnitt der Ergebnisse:

Eigentlich war ich sehr froh, scheinbar für 8k und random eine etwas schneller durchlaufende Kombination an Einstellungen gefunden zu haben (grüne Zeile, 179 Sekunden) - aber wenn ich dieselben Werte jetzt nochmal fahre im Benchmark, dann kommt eine viel längere Dauer heraus (gelbe Zeile, 368 Sekunden)...
(leider sieht man in der Tabelle die Spaltennamen nicht gut.)
Irgendwo muss noch etwas anderes versteckt sein...
Interessanterweise haben die meisten Optionen wenig Einfluss (wobei ich sie erstmal in vielen Bereichen, vielleicht etwas extrem variiert habe).
Aber immerhin schlüssig ist, dass für 8k ashift 13 und recordsize von 8k vorteilhaft sind.
Die PCIe-Adapter für die SSDs haben übrigens LEDs, die echt hell blinken - da sieht man, dass sie meistens eher abwechselnd statt synchron blinken. Aber ob das überhaupt etwas zu sagen hat, kann ich nicht so wirklich einschätzen...

 

[gea]

Auch wenn es Aspekte dafür gibt 8k physical blocksize (ashift13) den 8k Blöcken der VM vdisk mit 8k ZFS recsize anzugleichen, so ist das doch in zwei Punkten kontraproduktiv, nämlich der ZFS Effektivität und der allgemeinen Schreibperformance. ZFS arbeitet mit dynamischen Blöcken bis zu recsize. Eine Schreibaktion <8k wird immer mit 8k ausgeführt, aich bei großen recsize Einstellungen. Im Gegenzug sind alle ZFS Optionen wie Prüfsummen, Compress oder Verschlüssellung immer maximal auf ZFS Blöcke in recsize bezogen und das ist bei immer kleinen Blöcken dann ineffizient. Zudem kommt dass Schreibaktionen bei kleinen Blöcken (wie man an einem Atto Benchmark gut sehen kann) bis vielleicht 64k sehr viel langsamer sind wie bei größeren Blöcken auch bei SSD. Ich würde daher die ZFS recsize nicht unter 32-64k setzen, auch nicht bei Datenbanken oder VM Storage. Für die meisten Fälle ist default 128k ein guter Kompromiss, für einen Mediafiler eher 512k-1M.

z.B. ein Atto Benchmark mit unterschiedlich großen Datenblöcken bei einer SSD

 

[mmoolifu]

ja, dem würde ich generell auch zustimmen.
Bei diesem Benchmark kann ich bei fio ja auch die Blocksize vorgeben und variieren (in Schleifen verschiedene Größen durchprobieren), und das wird dann auch schneller, trotz recordsize 8k - das lasse ich gerade nochmal durchlaufen.

In der Zwischenzeit ist mir aber etwas anderes aufgefallen: die Reihenfolge scheint einen Einfluss auf die Ergebnisse zu haben - das sollte aber eigentlcih nicht sein. Irgendwo muss noch ein weiteres Problemchen vergraben sein...
Hier das Beispiel dazu:

Die beiden links in gelb markierten Zellen müssten eigentlich in derselben Reihenfolge auftauchen, wenn alles pico-bello reproduzierbar wäre. Aber das tun sie nicht...

 

[gea]

ja, dem würde ich generell auch zustimmen.
Bei diesem Benchmark kann ich bei fio ja auch die Blocksize vorgeben und variieren (in Schleifen verschiedene Größen durchprobieren), und das wird dann auch schneller, trotz recordsize 8k - das lasse ich gerade nochmal durchlaufen.

Das Problem bleibt. Mit recsize=8k ist das die maximale Blockgröße in die ZFS die zu schreibenden Daten portionieren kann. Eine größere Schreibaktion kann eventuell durch den RAM Schreibcache noch optimiert werden, dennoch werden max 8k Blöcke geschrieben.

Der Hauptgrund für VMs und Datenbanken eine reduzierte ZFS recsize überhaupt zu nutzen, trotz Einbußen bei der Schreibperformance und ZFS Effizienz ist dass im Schnitt weniger Daten verarbeitet werden müssen und das System damit in diesem Sonderfall insgesamt effizienter arbeitet. Bei Festplatten mit ihren geringen iops ist der Effekt zwar größer als bei SSD aber auch die sind bei 8k Schreiben/lesen relativ langsam..

 

[mmoolifu]

ja, in der Tat ist es unter 128K Blockgröße schneller mit resordsize 8K, darüber jedoch ist es mit dem default von 128K schneller:

Da bei 4K der Unterschied beim Schreiben ca. 3 zu 4,7 und bei 8K ca. 6,1 zu 9,1 ist, wäre das die Wahl - wenn es denn dem realen Anwendungsfall entsprechen würde....
So gesehen wäre es wohl sinnvoll, mit fio einen benchmark zusammenzubauen, der dem Anwendungsfall etwas näher kommt, als statisch dieselbe Blockgröße zu nutzen

Trotzdem tun sich mir Fragezeichen auf, denn unerklärlich scheint mir die grüne Zeile ein paar Posts weiter oben - dort ist die Performance viel besser, und mit denselben Parametern ein/zwei Tage später schlechter (lila Zeile). Höchstens, dass TRIM unbedacht ausgeführt worden sein könnte, war mir noch als Idee gekommen - dem scheint aber nach Blick auf den Timer nicht so.
Bleibt noch, dass die Reihenfolge der Benchmarks einen Einfluss hätte. Das scheint bei dem im Post davor zu sein, denn da ist einmal nvme1n1 schneller als nvme4n1, in der nächsten Runde ist es umgedreht. Als einziger Grund laut Parametern/Tabelle kommt zio_dva_throttle_enabled in Frage - aber das ergibt für mich keinen Sinn.
Außer beim Wechsel der Blockgröße erstellt das Skript immer einen neuen Pool für den Benchmark mit fio - an irgendeinem Cache sollte es also auch nicht liegen

 

[mmoolifu]

noch ein Zwischenergebnis:
via https://github.com/OtherJohnGray/ashiftio festgestellt, dass ich wohl unpassende Parameter für fio verwendet habe. Dort wird dies genutzt:

"fio --name=random-read  --ioengine=posixaio --rw=randread --bs=4k --size=40m --numjobs=1 --iodepth=1 --runtime=$seconds --time_based"
"fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=4g --numjobs=1 --iodepth=1 --runtime=$seconds --time_based"
"fio --name=random-read  --ioengine=posixaio --rw=randread --bs=64k --size=40m --numjobs=16 --iodepth=16 --runtime=$seconds --time_based"
"fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=64k --size=256m --numjobs=16 --iodepth=16 --runtime=$seconds --time_based"
"fio --name=random-read  --ioengine=posixaio --rw=randread --bs=1m --size=40m --numjobs=1 --iodepth=1 --runtime=$seconds --time_based"
"fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=1m --size=16g --numjobs=1 --iodepth=1 --runtime=$seconds --time_based"

Also als ioengine hier posixaio statt libaio und ohne direct=1.
Außerdem wird sinnigerweise für den Benchmark das erstellte zfs Filesystem ohne Cache erstellt - das hatte ich bisher auch nicht gemacht - wäre aber zwecks Hardware-Einschätzungen schon nicht verkehrt:
zfs create -o acltype=posixacl -o dnodesize=auto -o normalization=formD -o atime=off -o xattr=sa -o primarycache=none -o logbias=throughput -o sync=always -o recordsize=$recordsize -o mountpoint=/testpool/$recordsize testpool/$recordsize

Dadurch kommen die Messwerte beim mirror schon ein wenig näher an die Angaben laut Datenblatt der SSDs:

Write performance in MiB/s at various ashifts for mirror nvme1n1 nvme3n1


ASHIFT    4K read   4K write   64K read  64K write  128K read 128K write
========================================================================
    12        115         12       1868        943       6603        725
    13        114         11       1951        930       6578        730
    14        114         11       1945        931       6498        722
    15        114          9       2016        910       6556        710
    16        114          8       1932        906       6396        703

Dies spricht auch eher für ashift 12 statt 13 - bei den bisherigen Testläufen war oft ashift 13 ganz knapp vorne.
Davon werde ich mal die Performance in der VM beim Dateien kopieren versuchen zu messen...

 

[mmoolifu]

also der Aufruf von fio war schon relevant anzupassen, denn so wie bisher war es mit direct=1 und sync=sync ja doppelt gemoppelt, wenn der zpool eh auf sync=always eingestellt ist.
Nun lässt sich erkennen, dass die Performance auf den ersten Blick am meisten von der Blockgröße abhängt - und die hilfreichen Einstellungen, um sie zu verbessern, leider je nach Blockgröße unterschiedlich sind, siehe folgende Bilder: 4K, 8K, 128K, 1MiB.
Das einzige, was bei diesen Testläufen allgemein feststeht, ist, dass die default Einstellungen von zfs (graue Markierung) eher zu kleineren Zahlen führen, egal bei welcher Blockgröße...

Leider korrespondiert hier auf den ersten Blick nicht so viel mit der Geschwindigkeit gleichartig auch mit den Blockgrößen. Außer die drei Parameter zu Scatter, ARC Compression und DVA Throttle (auch aus vorherigen Versuchen, aber es ist nur einer von den dreien, soweit ich mich erinnere). Das ist natürlich schon mal etwas, aber auf der anderen Seite ist es bei kleinen Blöcken schneller mit primarycache=none, und bei größere Blöcken schneller mit primarycache=all, wobei metadata mal hier und mal da dazwischen auftaucht, und immer ein paar Ausreißer dabei sind...

Also unterm Strich scheint mir das zu bedeuten, dass man die Parameter eher im laufenden System mit der echten Arbeitsbelastung Schritt für Schritt testen sollte. Der Einstieg mit solchen Testläufen als Übersicht ist dazu bestimmt hilfreich, aber auch das Gefundene sollte man am echten System nochmal verifizieren - in dem Sinne, ob das 'schnelle' dort auch 'schnell' ist. Das ist bei 1MiB Blockgröße immerhin ein Unterschied von 712 zu 956 MiB/sec schreiben in diesem Einzelfall....