Hohes I/O delay bei Kopiervorgängen innerhalb der VMs

[illumina7]

Moin zusammen,
ich habe ein seltsames Phänomen mit meinen proxmox hosts.
Beide Hosts im Cluster haben jeweils lokalen ZFS Storage mit 10 SATA Intel Enterprise SSDs im ZFS Raid-Z2 bzw. Raid-Z1.
Beide proxmox sind jeweils mit 2x10GBit/s LACP am Switch angebunden, zusätzlich haben die beiden Hosts noch 2x10GBit/s dedizierte Netzwerkkarten für die Replikation.
Perfomance ist soweit auch alles im grünen Bereich, außer ich kopiere große Dateien innerhalb der VMs oder zwischen den beiden Hosts.
Dann springt das I/O delay auf 40-50-60% hoch und einzelne VMs fangen an Netzwerkverbindungen zu trennen oder sich komplett aufzuhängen.
Also es geht dann schon Richtung freezen der hosts, auch das WebUI reagiert dann sehr verzögert, jetzt hatte ich heute die ersten beschädigten User Profile Disks unserer RDS Farm, die ich aus dem Backup zurückspielen musste. Beim Zurückkopieren der UPDs aus dem Backup fliegen dann ständig andere User raus, wir sprechen hier von Kopiervorgängen mit 20-30GB großen UPD VHDX Files, das kann doch nicht sein, dass sowas den kompletten Server crasht.

=> Was mir in dem Zusammenhang aufgefallen ist - kopiere ich große Files "von außerhalb", also nicht innerhalb einer VM auf den hosts oder zwischen den beiden proxmox, sondern z.B. per SFTP auf die ZFS pools, dann tritt das nicht auf. Also ich kann da ~500GB VHDX rüber kopieren, laufen durchgehend nahe am 10Gbit/s Netzwerklimit, I/O delay bleibt bei unter 1% und keine VMs werden abgeschossen.

Ich bin jetzt recht frisch bei pve dabei, so eigentlich echt begeistert und zufrieden, aber das Problem muss ich irgendwie identifizieren und lösen. Ich kann so nicht mal eine Live-Migration zwischen den beiden hosts für Wartungsarbeiten durchführen, weil es mir dann reihenweise unsere User aus dem System wirft.

Wo kann ich anfangen mit der Fehlersuche? Über Tipps wäre ich sehr dankbar. Sagt mir welche Infos ich für die Fehlersuche mitteilen müsste, dann sammle ich diese.

Edit:

zpool iostat -v
                                                    capacity     operations     bandwidth
pool                                              alloc   free   read  write   read  write
------------------------------------------------  -----  -----  -----  -----  -----  -----
raid-z2                                           1.79T  6.93T  1.39K  3.18K  8.51M  44.7M
  raidz1-0                                        1.79T  6.93T  1.39K  3.18K  8.51M  44.7M
    ata-INTEL_SSDSC2KG960G8_PHYG1085058S960CGN        -      -    156    326   954K  4.50M
    ata-INTEL_SSDSC2KG960G8_PHYG108500YN960CGN        -      -    129    325   788K  4.43M
    ata-INTEL_SSDSC2KG960G8_PHYG1085010A960CGN        -      -    156    326   954K  4.50M
    ata-INTEL_SSDSC2KG960G8_PHYG108504PT960CGN        -      -    129    325   788K  4.43M
    ata-INTEL_SSDSC2KG960G8_PHYG1085047F960CGN        -      -    156    326   954K  4.50M
    ata-INTEL_SSDSC2KG960G8_BTYG12710CPU960CGN        -      -    129    325   788K  4.43M
    ata-INTEL_SSDSC2KG960G8_BTYG12710BJF960CGN        -      -    156    326   954K  4.50M
    ata-INTEL_SSDSC2KG960G8_BTYG12710B6W960CGN        -      -    129    325   788K  4.43M
    ata-INTEL_SSDSC2KG960G8_BTYG12710B60960CGN        -      -    156    326   954K  4.50M
    ata-INTEL_SSDSC2KG960G8_PHYG126204BV960CGN        -      -    129    325   788K  4.43M
------------------------------------------------  -----  -----  -----  -----  -----  -----
rpool                                              298G   590G     25     44   797K  1.73M
  mirror-0                                         298G   590G     25     44   797K  1.73M
    ata-INTEL_SSDSC2KG960G8_PHYG1085010V960CGN-part3      -      -     12     22   398K   885K
    ata-INTEL_SSDSC2KG960G8_PHYG103101KP960CGN-part3      -      -     12     22   399K   885K
------------------------------------------------  -----  -----  -----  -----  -----  -----

Das sieht alles nach sehr geringen Werte aus? Die SSDs hängen an einem Adaptec SmartRaid Controller, der im HBA Modus läuft (das kann der out of the box, habe nicht irgendwie eine spezielle fw geflasht o.ä., neueste oirignal fw habe ich allerdings eingespielt).

 

[Dunuin]

Wie sehen denn die VM Konfigs und Storage Konfigs aus? Z.B. die Volblocksize noch 8K oder einen anderen Cache als "none" gewählt? Virtio SCSI wird benutzt? IO uring?

 

[illumina7]

Volblocksize ist 64K, Cache steht auf Write Back, so sieht die Confg eines RDS aus:

agent: 1
balloon: 0
bios: ovmf
boot: order=scsi1
cores: 16
cpu: host
efidisk0: raid-z2:vm-101-disk-0,efitype=4m,format=raw,pre-enrolled-keys=1,size=1M
ide2: none,media=cdrom
machine: pc-q35-5.1
memory: 32768
meta: creation-qemu=7.1.0,ctime=1674391793
name: Terminal01
net0: virtio=1E:41:B5:5E:40:37,bridge=vmbr0,firewall=1
numa: 1
onboot: 1
ostype: win10
scsi1: raid-z2:vm-101-disk-1,cache=writeback,discard=on,format=raw,iothread=1,size=100G,ssd=1
scsihw: virtio-scsi-pci
smbios1: uuid=e31563c2-344c-47a9-916b-756dcf4bc726
sockets: 1
tablet: 0
tags: Terminalserver
vmgenid: e5857964-9fa0-4cd3-b217-18e5bd7dd801

Alle Windows VMs sind vergleichbar konfiguriert.

 

[Dunuin]

Ist das IO Delay nur gut wenn du von außen etwas auf den Host kopierst oder auch wenn du von außen etwas in die VM schreibst? Wenn du von außen auf den Host schreibst, schreibst du dann in ein Dataset oder ein Zvol?

NTFS ist mit einer 64k Clustersize formatiert?
Hast du es mal ohne writeback versucht, damit nicht dreifach im RAM gecacht wird?

 

[illumina7]

Von außen in eine VM habe ich tatsächlich noch nicht mit größeren Files probiert, ich vermute stark, dass es sich hier ähnlich verhält. Schon beim Kopieren innerhalb einer VM zwischen zwei Disks tritt der quasi-freeze der VMs auf.
Bis jetzt habe ich immer ins Dataset kopiert per SFTP, dabei kam es nicht zu dem Verhalten, I/O Delay ist marginal angestiegen, auf 1-3%.

NTFS ist per default mit 4K formatiert, macht das einen großen Unterschied? Ich meine dafür müsste ich ja ~25 Win Server platt machen und neu aufsetzen, der Aufwand wäre derzeit absolut nicht umsetzbar.

Ohne Writeback sind die VMs schon sehr träge, ob es dann auch zum Freeze kommt müsste ich heute Abend mal Testen.

Edit: ich habe noch einen 3. proxmox host als Testserver und für den pbs. Ist eine wesentlich ältere Maschine und mit ziemlich langsamen HDDs, prinzipiell steigt dort ach das i/o delay beim Kopieren innerhalb der VMs, aber kaum über 15% und es kommt nicht zum freeze. Konfiguration ist im Wesentlichen die Gleiche wie bei den beiden Produktiv-Systemen. An dem Test pve habe ich eben das Caching für einen Test-RDS und den zugehörigen Fileserver abgeschaltet und gefühlt wurde das delay geringer und die Performance beim Kopieren besser.
Nebenbei habe ich das ganze per iotop beobachtet, was mir hier aufgefallen ist, in der VM kopiert es die große Datei mit 30-60MB/s, während mir iotop aber gleichzeitig anzeigt, dass Total Disk Write bei ~200MB/s liegt. Bei den einzelnen Prozessen zeigt es mir aber keinen Einzigen an, der mit so viel Bandbreite schreibt.
An den beiden Produktiv-Systemen kann ich erst heute Abend testen, kann jetzt nicht schon wieder alles lahmlegen. Solange keine großen Datenmengen kopiert/verschoben werden, läuft es soweit "normal".

 

[mow]

in der VM kopiert es die große Datei mit 30-60MB/s, während mir iotop aber gleichzeitig anzeigt, dass Total Disk Write bei ~200MB/s liegt. Bei den einzelnen Prozessen zeigt es mir aber keinen Einzigen an, der mit so viel Bandbreite schreibt.

Der zählt evtl. doppelt, also das zfs device und nochmal die einzelnen Laufwerke obendrauf.

 

[Dunuin]

NTFS ist per default mit 4K formatiert, macht das einen großen Unterschied? Ich meine dafür müsste ich ja ~25 Win Server platt machen und neu aufsetzen, der Aufwand wäre derzeit absolut nicht umsetzbar.

Naja, mit einer Volblocksize von 64K speichert das Zvol halt alles in fixen 64k Blöcken. Schreibst du 1000x 4K blocke in NTFS als Sync Writes, dann muss ZFS da 1000x 64K schreiben. Also bei Random Sync Writes kann das schon echt übel kommen. Bei sequentiellen Async Writes nicht ganz so wild, da dann halt die 4K Blöcke im Cache gesammelt und dann 16x 4K Blöcke als 1x 64K geschrieben werden.

Datasets wiederrum nutzen nicht deine Volblocksize sondern die Recordsize. Default ist da 128K und diese ist nicht fix. Bei einer Recordsize von 128K kann ZFS je Datei selbst entscheiden, ob es die Datei als ein 4K, 8K, 16K, 32K, 64K oder als 128K Records speichern will.
Die selbe Workload kann sich also sehr stark zwischen Datasets und Zvols unterscheiden,

Ohne Writeback sind die VMs schon sehr träge, ob es dann auch zum Freeze kommt müsste ich heute Abend mal Testen.

Writeback cacht halt alle Writes nochmal zusätzlich im RAM. Das ist dann so lange schnell bis dein RAM voll ist, dann bricht es ein. Je mehr du schreibst, desto schneller läuft dein RAM voll.

Daher meine Idee, dass das vielleicht am Zvol, Caching oder der Virtualisierung liegt, wenn Datasets auf dem Host sonst performant sind.

Nebenbei habe ich das ganze per iotop beobachtet, was mir hier aufgefallen ist, in der VM kopiert es die große Datei mit 30-60MB/s, während mir iotop aber gleichzeitig anzeigt, dass Total Disk Write bei ~200MB/s liegt. Bei den einzelnen Prozessen zeigt es mir aber keinen Einzigen an, der mit so viel Bandbreite schreibt.

Ja, klingt nach Write Amplification. Die 64K sind für deine Workloads vielleicht einfach zu hoch.

Außerdem nicht vergessen, dass IOPS nicht mit der Anzahl der Disks skalieren, sondern mit der Anzahl der Vdevs. 10 SSDs im Raidz1/2 haben also keine bessere IOPS Performance als eine einzelne SSD.

 

[illumina7]

Danke für deine ausführlichen Erläuterungen, das klingt auch alles zimlich schlüssig, ich weiß jetzt nur eben nicht wo ich ansetzen kann.
Wahrscheinlich macht es Sinn erstmal das Caching abzuschalten und sehen wie es sich dann verhält. Für Raidz1/2 hatte ich mich vorwiegend entschieden, weil der Großteil unseres Workloads Lesen ist, im Prinzip sollte die Performance einer einzelnen DC S4610 960GB doch ausreichend sein?
Eine weitere Möglichkeite wäre: erst alle VMs auf einen Node verschieben, bei dem anderen Node den ZFS Pool komplett löschen und z.B. als Raid10 neu einzurichten. Alle VMs auf Node1 und das Gleiche nochmal an Node2 durchführen. Wäre das ohne Pobleme machbar?

 

[Dunuin]

Erstmal würde ich gucken ob es ohne Writeback konsistenter läuft.
Dann würde ich gucken ob eine kleinere Volblocksize hilft. Die kann man nur verändern indem man die Vzols neu erstellt, da würde es sich also anbieten ein paar leere Zvols zu erstellen und diese dann mal mit fio benchmarken. Dann würde man ja sehen, ob da z.B. eine 16K Volblocksize bessere Performance liefert als eine 64K Volblocksize.
Performance mit Raid10 könnte man wie du schon sagtest nur testen, indem man den Pool löscht und neu aufbaut und da vorher dann alle VMs migiriert. Mit 10 Disks im Raid10 sollte dann eine Volblocksize von 16K oder 32K möglich sein wenn du ashift=12 nutzt. Und es wären 5 Vdevs also 5-fache IOPS Performance. Je nach Workload könnte das dann 5 bis 20 mal schneller sein.

Wenn du da schon einen Test-Node hast, solltest du einfach mal verschiedenste Kombinationen austesten und dann gucken, was für deine Workload am besten läuft.

 

[illumina7]

Ich habe jetzt an einer VM das Caching deaktivert (Default (No cache)), wenn ich innerhalb der VM ein crystaldiskmark laufen lasse, dann bekomme ich aber nach wie vor exorbitant hohe Werte?
Kommt das durch den disk write cache? Wobei das den hohen sequentiellen Read Wert trotzdem nicht erklärt, zumindest für mich aktuell nicht. Ich beziehe mich hier mal auf die Doku bezüglich der Cache Modi https://pve.proxmox.com/wiki/Performance_Tweaks

So wäre die Performance ja auch noch voll iO, mit writeback verdoppeln sich die Read Werte ungefähr, Write ist ca. 1GB/s höher, ich beziehe mich jetzt mal als Referenz auf die sequentiellen Benches. Die Random R/W Benches fallen ziemlich unverändert aus.
Btw zum Zeitpunkt des Benchmarks waren alle anderen VMs auch noch Up.

 

[Dunuin]

Ich habe jetzt an einer VM das Caching deaktivert (Default (No cache)), wenn ich innerhalb der VM ein crystaldiskmark laufen lasse, dann bekomme ich aber nach wie vor exorbitant hohe Werte?
Kommt das durch den disk write cache? Wobei das den hohen sequentiellen Read Wert trotzdem nicht erklärt, zumindest für mich aktuell nicht. Ich beziehe mich hier mal auf die Doku bezüglich der Cache Modi https://pve.proxmox.com/wiki/Performance_Tweaks

CrystalDiskMark macht nur Async Writes. Selbst ohne Writeback cacht ZFS noch im RAM des PVE Hosts und am Ende cacht auch noch einmal deine SSD selbst in ihrem eingebauten DRAM-Cache. Mit writeback würde alles nur noch ein drittes mal gecacht werden. Und bezüglich Lesen cacht Windows ja selbst auch noch, zusätzlich zum ARC von ZFS und dem Cache der SSDs.
Will man da nicht nur RAM benchmarken, muss man schon ein Tool nutzen was auch Sync Writes für das Benchmark nutzen kann, wie z.B. fio. Und für Reads müsste man dann auch noch für das Zvol den ARC dektivieren (ZFS option: "primarycache=metadata" oder "primarycache=none" statt "primarycache=all")

 

[Neobin]

scsi1: raid-z2:vm-101-disk-1,cache=writeback,discard=on,format=raw,iothread=1,size=100G,ssd=1
scsihw: virtio-scsi-pci

iothread=1 bringt übrigens nichts, wenn der Controller auf: virtio-scsi-pci steht. Dafür musst du ihn auf Single: virtio-scsi-single umstellen.
Ist mittlerweile auch Standard für neu erstellte VMs und dementsprechend empfohlen.

 

[xqlusive]

das Problem muss ich irgendwie identifizieren und lösen

Konntest Du das mittlerweile?

 

[illumina7]

Ja, das lag wohl am zusätzlich aktivierten Caching der vdisks. Irgendwo gibt es bei meinen Maschinen hier einen Flaschenhals, seitdem ich das Caching auf default/no umgestellt habe funktioniert alles problemlos und in den VMs selbst merkt man keinen Unterschied.