Proxmox mit Shared NFS via 10Gb und Performanceproblemen

[Gelöschtes Mitglied 117520]

Hallo Zusammen,

in meinem kleinen Homelab habe ich einen HP Microserver Gen8 (Celeron/8GB RAM) mit 4x 4TB HDs und Ubuntu Server 16.04 mit ZFS On Linux laufen. Verbaut ist außerdem eine Mellanox ConnectX 10Gb PCIe Karte, die mit einem 10Gb Switch (TP-Link) verbunden ist. Dort angeschlossen sind ebenfalls meine 2 Nodes. Auf denen läuft Proxmox; beide verfügen jeweils wieder über eigene Mellanox ConnectX 10Gb PCIe Karten, die wiederum mit dem Switch verbunden sind.

Nun habe ich das NFS Share eingebunden und stoße auf folgende Probleme: (Zitate aus meinem Blogpost zu dem Thema)

Ich habe auf der Node 1 in den vergangenen Tagen einigen Lern-VMs installiert, namentlich Windows 7, Windows 10, Windows Server 2012 R2 (2x) und Windows Server 2016. Ja, man ich habe da noch einiges zu lernen, trotz M$ Zertifikaten im Sammelsorium. Die Windows 7 VM war wohl zu viel und so betrachte ich stirnrunzelnd den htop mit diesen heftigen Werten: 111 Load (1min).

Einen Load von 111 habe ich noch nie zu Gesicht bekommen. Der Wert schnellte sogar noch auch 150 hoch. Einen Schuldigen konnte ich jetzt nicht direkt ausmachen, da die CPU Last auch nicht wirklich hoch war. Für mich sieht es so aus, als kommt der NFS-Share nicht mit (och nee…).

Das herübermigrierte IPAM (Container) ließ sich zwar starten, aber auf die Webseite der Anwendung kam ich gar nicht drauf. Nur einen „Bad Gatway“ vom darin installierten nginx bekam ich entgegengeworfen.

Ich vermute die Schuld liegt hier auf meiner Seite. Nach dem Zusammenbauen habe ich einen Server nach dem anderen gestartet. Natürlich zuerst das NAS, denn Node 1 hat ja schließlich die VMs & Container auf dem NFS-Share liegen. Doch da passierte nichts bzw es wurde mir angezeigt, dass ich nicht auf das NFS-Share zugreifen könne. Ah! Im Keller entdeckte ich dann den vermeintlichen Grund: der Cisco DAC (10 Gbps Kupfer-Kabel) steckte nicht richtig im Switch. Einmal gezogen und wieder gesteckt und siehe da: die LED begann lieblich grün zu leuchten.

Doch irgendwie wollte es immer noch nicht. Nach einer Stunde des Debuggens und Haare raufens kam ich dann darauf: MTU 9000! Na klar! Ich habe für den Port den Jumbo Frame nicht aktiviert. Gesagt, getan und schon mountete das NFS-Share wieder. Die VMs und Container starteten und ich dacht nun sei alles wieder gut. Scheinbar nicht. Naja.. nun heißt es den Fehler finden. Die virtIO Treiber habe ich überall in den VMs installiert; wieso so ein Load auftritt kann ich mir nicht so wirklich erklären, aber dieses Phänomen ist so schlimm, dass es sämtlich anderen VMs und Container lahmlegt.

Ich würde mich sehr freuen, wenn mir jemand evtl. einen Fehler aufzeigen könnte, evtl. habe ich ja NFS falsch konfiguriert (hier mal ein auszug aus der sehr übersichtlichen exports):

/storage/vms	10.10.10.2(rw,async,no_subtree_check,root_squash,all_squash) 10.10.10.3(rw,async,no_subtree_check,root_squash,all_squash)

Aktuell habe ich ESXi installiert, aber ich muss gestehen, dass die WebUI eine Katastrophe ist, der Mangel an sparsamen Containern, keine integrierte Backupfunktion usw, lassen mich nach nur wenigen Stunden mit ESXi meinen Proxmox zurückwünschen.

 

[besterino]

Moin!

Vorab: Kenne mich mit Proxmox null aus und bin sicher auch kein Linux-Performance-Tuning Guru. Aber: htop zeigt doch die CPU-Auslastung? Wieso sagst Du, der Wert sei "heftig" und gleichzeitig dass die "CPU-Last nicht wirklich hoch war? Htop lügt doch nicht?

Also Grundfrage: wo sitzt die Performance-Bremse. Von dem was Du schilderst, muss das überhaupt nicht zwingend Netz oder Storage sein. Wie sieht zum Beispiel die Hardware von Node1 aus? Wenn der Host keinen RAM hat und die VMs permanent in ihren virtual Disks RAM swappen wie blöde, hilft dir z.B. auch 10G nix.

Davon ab sind HDDs wegen ihrer mauen IO-Performance als VM-Storage m.E. eher "solala". Wenn da 5 Windows VMs parallel drauf Booten, halleluja. Oder ein größeres Windows Update fahren - da reicht wahrscheinlich EINES und die anderen VMs frieren gefühlt ein, wenn man da auch nur ein Progrämmchen starten will.

 

[Gelöschtes Mitglied 117520]

Also Load heißt das Jobs im Queue hängen, das muss nicht zwangsweise mit hoher CPU Last einhergehen.

Die Daten von den Nodes habe ich in die Signatur geschrieben, ebenso die von dem NAS. Könnte mir evtl. vorstellen, dass hier 8GB wegen ZFS zu wenig sind. Dann müsste ich evtl. etwas RAM von den Proxmox Servern rausnehmen und das NAS auf 16GB bringen und die Proxmox auf 28GB jeweils (glaube aber damit versaue ich mir dann das Dual Channeling).

Das mit den Festplatten mag natürlich sein, sind auch keine SAS, also langsamer drehende.

 

[besterino]

Ich würde wohl als erstes einmal mit einer WinVM starten (ohne das was anderes auf dem Proxmox lüppt) und dann mal "diskbenches" auf Laufwerk C machen. Wenn das unauffällig ist, dann mal alle einzeln so durchgehen. Dann weißt du schonmal, ob bei einer VM bereits irgendwas schief läuft.

Funzen die alle für sich, wirds etwas kniffliger. Denn klar ist, dass du jetzt für aussagekräftige Ergebnisse nicht einfach 2 VMs parallel so testen kannst. Die Performance wird deutlich überproportional einbrechen (also nicht einfach 50% auf beiden Kisten).

Ich hatte mich hier (10G-Netzwerk; Datentransferoptimierung WinLinux/BSD/OS/etc.) mal länger mit der Suche nach Bottlenecks beschäftigt. Spaß ist jedenfalls anders.

Immerhin solltest Du mit iperf zwischen Linux-NAS und proxmox erstes vernünftiges Feedback zum Netz bekommen (anders mit Windows). Auch kannst du mit DD das Storage auch aus Sicht von Node 1 mal anschauen. Wenn das richtig fluppt, musst Du eben wieder die Ebene höher zu den VMs.

Ist Node für sich unauffällig, das gleiche mit Node 2. Funzt da auch alles und macht die Kombination das Problem, würde ich - wie schon im Anfangsverdacht - aufs Storage tippen.

Soweit der theoretische Ansatz. Wenn Du die Möglichkeit hast kannst du ja auch schauen, ob du mal im NAS testweise eine oder mehrere flotte SSDs einsetzt und die VMs mal darauf verschiebst. Ist's dann weg, kannst Du Dir die theoretische Fehlersuche quasi sparen...

Hast du dann die Ursache, gibt es im Zweifel immer mehrere Lösungsansätze (statt reines SSD VM Storage z.B. "nur" SSD als ZFS Cache).

 

[VirtuGuy]

bitte folgende Befehle unter Last probieren:

1. nfsstat -rc

2. iostat -k -h n 5

 

[Gelöschtes Mitglied 117520]

Hallo Zusammen,

@besterino:
Danke für das Feedback! Ich habe bereits einige Tests gemacht gehabt (und zu dem Zeitpunkt sah alles noch sehr gut aus (ist einige Tage her)). Die Tests könnt Ihr hier einsehen.

iperf liefert mir sauber zwischen 9,3 und 9,8 Gbps - die Verbindung ansich ist in Ordnung.

Ich hatte wie geschrieben vorgestern Abend mal ESXi installiert mit dem Ergebnis, dass nur wenige Stunde später die virtuelle Maschinen standen. Da ich nicht zu Hause war, habe ich es auch nicht diagnostizieren können und generell geht meine Vorliebe sowieso eher Richtung Proxmox - ganz einfach weil es mir mehr Freiheiten erlaubt also ESXi (fühle mich generell auf Linux-Systemen heimischer, weil ich eh den ganzen Tag damit/darauf arbeite). Ich werde heute Abend mal Proxmox frisch installieren auf Node 1 und dann auf Node 2 auch noch einmal - erstmal ohne Cluster und parallel testen, ob ich da Unterschiede sehe.

Ich habe gestern von einem YouTuber der ein größeres Homelab hat eine Antwort auf meine Frage bekommen, Link zum Video hier, hier mal die Kommentare:

Frage von mir:

Thanks for this great video! This switch is very impressive

A question with regards to your Proxmox installation, that I've seen in a previous video you posted a while ago: do you use a share storage in your Proxmox? A NFS or iSCSI Share maybe? I'm asking because I tried it with my setup (HP Microserver with ZFS on Linux w/ Mellanox 10Gb card -> 10Gb Switch -> Proxmox Server with also a Mellanox 10Gb card) and I quickly ran into problems with the performance. This was very unfortunate, because I run two identical Proxmox servers and my plan was to build a cluster with share NFS storage. In the end, even Containers were so painfully slow, that I stopped the servers some days ago. I'm just wondering if you ran into such issues in the past, too?

Thanks!
Dennis

Seine Antwort:

Hi Dennis, I do use shared storage. The FreeNAS machine has got two main NFS shares, one for disk images and machine images and the other purely for backup. (they're separate due to different compression being run on them). I honestly wouldn't say its the fastest either, on the main array (6x 2TB Raidz2) I am only pulling around 400MB/s read and 350MB/s write. I am wondering if the core clock is holding back the system (shall experiment), however the main issue I have had has been singular machines swallowing all the read/write at anyone time. What helped was to set disk speed limits on the VM's. Although none of them can leverage the full filesystem speed, it prevents them from making other VM's unresponsive. I am still experimenting with the FreeNAS as VM storage, as you can maybe tell with my Proxmox machines still having local storage on them. Hope this kind of helps.

Es scheint also in der Tat ein Problem zu sein mit NFS-Storage und Proxmox, wenn ich das so richtig verstehe. Das man die Zugriffsgeschwindigkeiten bei Proxmox quasi vorgeben kann, ist mir neu.

@VirtuGuy:
Werde ich heute Abend ausführen, sobald ich den Proxmox nochmal frisch hochgezogen habe.

Evtl. ist das Bottleneck ja beim Proxmox auch der USB-Stick. Ich habe noch 2x 60GB SSDs rumliegen, evtl. machte es Sinn die Installation von Proxmox darauf zu machen.

PS. SSDs im NAS kann ich leider nicht einbauen. Der Microserver ist quasi mein produktives NAS für das Haus und da möchte ich auch nicht dran rumfummeln. Könnte mir höchstens vorstellen einen Tray für eine SSD zu kaufen (~15€ rum) und eine SSD als l2arc oder zil zu verwenden. Ich glaube aber nicht, dass das wirklich viel bringt (habe über die Jahre einige Threads und Blogposts gelesen, wo sich ZFS-Anwender eher enttäuscht darüber geäußert haben).

 

[Gelöschtes Mitglied 117520]

Guten Abend,

wie erwähnt habe ich heute Abend die Node 1 neu installiert. Diesmal auf eine 60 GB SATA3 SSD, statt auf einen USB-Stick. Des weiteren habe ich einen ZFS-Dataset gebaut der keine Kompression hat und diesen per NFS gemountet.

Aktuell installiere ich parallel auf das NFS-Share (via 10Gb Karte) drei VMs: Win 7, Win Server 2012 R2 & Win Server 2016. Dabei habe ich auf dem NAS und auf dem Proxmox die Werte wie oben angegeben gemessen.

Auf dem NAS:

# netstat -rc
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
default         192.168.2.254   0.0.0.0         UG        0 0          0 eno1
10.10.10.0      *               255.255.255.248 U         0 0          0 ens1
192.168.2.0     *               255.255.255.0   U         0 0          0 eno1

Linux 4.4.0-78-generic (nas) 	01.06.2017 	_x86_64_	(2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,83    0,00    1,51    3,31    0,00   94,34

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5,29    0,00    9,16   23,40    0,00   62,16

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4,61    0,00    5,94   32,79    0,00   56,66

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2,68    0,00    5,26   33,51    0,00   58,56

Auf dem Proxmox (Node 1):

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         192.168.2.254   0.0.0.0         UG        0 0          0 vmbr0
10.10.10.0      *               255.255.255.248 U         0 0          0 eth2
192.168.2.0     *               255.255.255.0   U         0 0          0 vmbr0

Linux 4.4.62-1-pve (node1) 	06/01/2017 	_x86_64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.75    0.00    2.12   33.95    0.00   57.18

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.91    0.00    1.96   55.24    0.00   38.89

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.35    0.00    1.30   39.94    0.00   57.40

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.32    0.00    1.66   56.47    0.00   39.56

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.36    0.00    1.96   53.85    0.00   42.82

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn


avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          31.63    0.00    5.01   35.17    0.00   28.19

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.52    0.00    4.86   28.95    0.00   43.67

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          15.30    0.00    3.43   31.77    0.00   49.49

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.63    0.00    4.61   45.22    0.00   31.54

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.21    0.00    3.57   66.30    0.00   19.92

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.30    0.00    3.23   58.62    0.00   19.86

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

Ciao
Dennis

 

[Trambahner]

Wenn Du NFS auf ZFS-Datasets mit HDDs als Pool hast und die Properties auf sync writes (=default) stehen hast, dann ist ein
ZIL quasi Pflicht, sonst bricht Dir die Io-Performance zusammen bei mehreren VM.
Oder man muss sync writes deaktivieren.

 

[Gelöschtes Mitglied 117520]

Hallo @trambahner,

ich hatte folgendes Flag gesetzt:

zfs set sync=disabled storage/vmstore

Erstellt habe ich das Dataset mit:

zfs create -o compression=off -o dedup=off storage/vmstore

und habe anschließend die Quota auf 500 GB gesetzt (was hier jetzt wohl eher nicht reinspielt). Außerdem habe ich für die Teste auch die Snapshots mit

zfs set com.sun:auto-snapshot=false storage/vmstore

deaktiviert.

Ich bin ehrlich gesagt kurz davor einen Haken an die knapp 500€ Investition in 10Gb zu machen und die 480 GB SSD aus dem Desktop hier unten als Storage einzubauen...

*Update*
Ich habe mich etwas mehr umgeschaut und scheinbar ist das ein durchaus beliebtes "Problem". Ich habe daher eben eine Samsung 960 EVO 500 GB NVMe SSD mit passendem PCIe x4 Adapter für den Proxmox bestellt. Das Experiment Cluster breche ich hiermit ab. Charmanter Vorteil: dadurch konnte ich mich nun an dem 32 GB ECC RAM aus "Node 2" bedienen und 16 GB davon in den Microserver stecken. ZFS wird sich darüber freuen.

Vielen Dank für Antworten. Was mich betrifft ist das Thema damit erstmal erledigt (zumindest bis ich mir ein SSD-NAS leisten kann ), aber evtl. haben ja noch andere dieses Problem.

 

[VirtuGuy]

Eine SSD ist natürlich gut, aber deine VM´s sollten eigentlich durch den Traffic nicht hängen bleiben. Für mich deutet es am ehesten nach zu wenig Ram in deinem NAS hin, 8gb sind halt nicht wirklich viel mit Ubuntu und ZFS.

Hast du ggf kein Swap eingerichtet, dies würde dann auch etwaige Hänger erklären?

 

[Gelöschtes Mitglied 117520]

Den RAM habe ich nun verdoppelt (auf 16 GB), Swap habe ich auf 0 gesetzt, weil Swap auf nem USB-Stick ist ja generell nicht so eine geile Idee Also daran sollte es auch nicht liegen..

 

[Trambahner]

Ok, Sync ist schonmal aus. Nebeneffekt: damit riskiert man natürlich potentiellen Datenverlust, da ZFS Daten als "write commited" an die zugreifenden Prozesse zurückmeldet, obwohl die Daten noch nicht geschrieben sind. Daher ggf. kleine USV vorsehen oder eben ein ZIL (braucht aber SSD die mit hohen Schreibmengen fertig wird und kürzest mögliche Schreib-Latenzen hat ).

Compression würde ich generell auf LZ4 stellen; das kostet fast keine CPU-Performance und spart viel Platz und Schreibvolumen auf den Pool wenn da VMs draufliegen.

Nebenbei bzgl. 10Gb: TCP-Optimierungen dafür hast gemacht (Jumboframes, größere Netzwerkbuffer, Rwin, etc.) ?

 

[Shiga]

Ist die Mellanox Karte nicht sehr CPU-Lastig? Könnte da nicht die schwache Celeron CPU den Flaschenhals darstellen? Welche Celeron ist es genau?

 

[bigghost]

Proxmox läuft auch mit einem NFS Share sehr performant..Nutze selber in unserem kleinen Proxmox Cluster mit 3 Nodes NFS.Das Storage dazu besteht aus CentOS mit 9 *1TB SAS 10k Platten
im RAID5. Da laufen 30 VM ´s sehr gut drauf.Aber bitte kein ZFS nutzen das ist ohne ZIL/L2ARC grottig langsam.

Starte mal auf einer Proxmox node das command pveperf über deinen NFS Mountpoint und poste die Werte.Hier ist besonders FSYNCS/SECOND interessant.

- - - Updated - - -

Diese Tests mit fio kannst du auch mal machen.
Das gibt uns einen guten Überblick wieviel IOPS dein Storage so leistet.
Aber bitte nur vom Proxmox Node aus

random r/w

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=66

random read

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread

random write

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite

 

[michaeljk]

Interessanter Topic, ich hatte vor einigen Monaten ein ähnliches Problem in Bezug auf Proxmox zusammen mit ZFS, allerdings auf einer rein lokalen Installation. Bei der Fehlersuche würde ich wie folgt vorgehen:

1. Die Geschwindigkeit der einzelnen HDDs auf der lokalen NFS-Maschine testen. Wenn nur ein Stecker/Kabel/Laufwerk ein Problem hat, zieht das den ganzen Rest herunter! Ebenfalls erkennt man dabei schnell die generelle Performance der Laufwerke und des Controllers.

2. Die Geschwindigkeit des ZFS-Pools direkt auf der lokalen NFS-Maschine testen. Welche vDev's kamen zum Einsatz (Mirrored, Raidz1, Raidz2, ...)? Für Virtualisierung bei 4 Laufwerken würde ich 2x Mirrored vDev's in einem Pool zusammenfassen (entspricht Raid10) um dort schon mal beste Performance zu gewährleisten.

3. Reine Netzwerkgeschwindigkeit (iperf) von einer Node zum NFS-Server testen, evtl. Fehler korrigieren/optimieren (wie bereits erwähnt Jumbo-Frames, Netzwerkbuffer, Rwin, ...). Ebenfalls die Einstellungen am Switch prüfen, Kabel und Steckverbindungen prüfen.

4. Geschwindigkeit des NFS-Shares testen, insbesondere im Hinblick auf Random I/O und nicht nur sequentiellen Transfers. Mount-Parameter beim Proxmox-Node prüfen und evtl. bei den Exports experimentieren/anpassen/optimieren.

5. Verschiedene Test-VMs aufsetzen (Windows / Linux) und mit unterschiedlichen Storage-Einstellungen die Geschwindigkeit innerhalb der jeweiligen VM testen. In den neuesten Proxmox-Versionen wird z.B. für Linux VMs immer als Bus/Device "SCSI" verwendet, da in den Options "VirtIO SCSI" per Standard gesetzt ist und dies die beste Performance bieten soll. Für Windows-Systeme gibt es hierzu auch entsprechende Treiber. Da du ein File-Based Storage mit NFS nutzt, hast du die Wahl zwischen dem RAW Disk Format und QEMU Image (qcow2) - letzteres bietet Snapshots und Thin-Provisioning, aber die Performance ist im Vergleich zu RAW auch ca. 10% geringer. Welche Einstellungen hattest du bei den einzelnen Laufwerken für den Cache ("No Cache" als Default)?


Du kannst in Proxmox beim Menüpunkt "Hardware" einer VM die jeweilige Harddisk auswählen und dann oben den Button "Disk Throttle" nutzen, um Lese-/Schreiblimits vorzugeben. Beispielsweise könnte man so einer VM mitteilen, nicht mehr Speed als der einer einzigen Festplatte zu verwenden. Wenn du Glück hast, wirst du spätestens ab Punkt 5 die Ursache des Problems finden, besser wäre natürlich schon früher in der Testkette. Leider treten solch hohe Loads aber erst dann auf, wenn mehrere VMs parallel laufen und an irgendeiner Stelle enorm I/O Last produziert wird, so dass sich das aufschaukelt. Wenn du ZFS als Ursache komplett ausschliessen willst, so könntest du temporär auch ein normales Linux Software-RAID10 mittels mdadm aufsetzen und vergleichen (bei vorhandenem Hardware-RAID Controller natürlich auch einen solchen).

Mich würden die Ergebnisse der Einzeltests auch sehr interessieren - intern habe ich zwar Proxmox auch nur auf einer Maschine mit lokalem ZFS-Pool am laufen, aber im Rechenzentrum wäre das Thema Cluster mit zentralem Storage mittlerweile sehr relevant

Edit:
Habe eben nochmal in deinem Blog drübergelesen - wie du bereits richtig angemerkt hast, ist der %iowait-Wert wesentlich zu hoch, Ursache kann hierfür aber theoretisch alles ab Punkt 5 aufwärts sein Wenn du "Glück" hast, ist lediglich ZFS dein Problem (z.B. in Verbindung mit dem wenigen RAM, der Pool-Konfig oder der fehlenden SSD). Hast du den 5. SATA Port bereits belegt? Ansonsten könnte man dort noch eine SSD anschliessen und als ZIL konfigurieren (wären dann aber nur 3 GBit/s). Einfachste Alternative wäre, die Festplatten mit dem vorhandenen ZFS-Pool zu entnehmen, andere Test-Festplatten ohne ZFS einzusetzen und darauf die NFS-Freigabe mal zum Vergleich zu machen. Wenn ein Hardware-RAID/mdadm Software-RAID dieselben Probleme verursacht, dann würde ich in Richtung Laufwerke/Kabel weitersuchen. Wie sind denn die einzelnen Laufwerke konfiguriert? Etwaige Stromsparmodi deaktiviert, per hdparm mal alles geprüft und auch die SMART-Werte gechecked? Write-Cache derzeit pro Laufwerk an oder aus?

Wie oben erwähnt, würde ich bei frischen Datasets direkt LZ4 Compression aktivieren. Moderne CPUs werden damit wenig belastet, dafür spart es Speicherplatz und die Lese-/Schreibperformance steigt normalerweise. Bei Verschlüsselung sieht das natürlich anders aus, zumal der kleine G1610 kein AES-NI kann Den Switch kannst du als Ursache ebenfalls schon ausschliessen? Kann man ja auch direkt testen, indem man eine Proxmox-Node direkt mit dem G8-NFS über 10 GBit verkabelt.

Die Problem-Ursache würde mich in deinem Fall sehr interessieren, zumal ich hier zusätzlich andenke den vorhandenen T20 durch einen kleinen Proxmox-Cluster aus mehreren G8 zu tauschen