VM / Host OOM bei starkem Write Load in VM

[Felix.]

Hallo zusammen,

Ich beobachte ein merkwürdiges Verhalten auf 2 Hosts. Wenn ich, zu Testzwecken oder durch real-world load, extreme *schreibende* IO Last erzeuge, kommt es auf dem Host ggfs. zu einer OOM Kondition. Bestenfalls sterben ein paar VMs - schlimmstenfalls stirbt der Host vollständig und muss neugestartet werden.

Meine bisherigen Tests fanden exklusiv auf ZFS statt. Auf einem HDD Array mit striped mirrors (3x 2 disks) und auf einem NVMe Mirror.
Es schaut so aus, als wäre der darunterliegende Storage egal, da das Problem selbst auf NVMe Platten gleichermaßen auftritt.
Auch konnte ich die Problematik scheinbar auf asynchrone Schreibzugriffe festmachen - setze ich das Volume der VM auf sync=always ist das Problem eliminiert, dazu habe ich sogar eine NVMe an meinen HDD Pool geklemmt um das näher zu testen... es lässt sich dort nicht mehr reproduzieren.
Ich habe auch ALLE disk cache modes durchprobiert - überall tritt das gleiche Problem auf, sofern das Volume darunter sync=standard oder sync=disabled gesetzt hat.

Die Problematik passiert NUR, wenn der Load aus der VM kommt - auf dem Host direkt kann ich mit fio Benchmarks drüber laufen lassen wie ich möchte, es kommt nicht zum OOM, der RAM peakt nicht schlagartig, es schaut alles erwartungsgemäß aus.

Ich beobachte das Problem schon einige Tage lang. Durch den ARC sind die Lesewerte exzellent, auch konnte ich keine OOM Kondition erzwingen durch massive Lese Benchmarks.
Die Schreibrate ist ebenso extrem (ich rede da von 5-10 GB/s), allerdings stockt dann jegliche I/O Aktivität vollständig und die RAM Nutzung explodiert auf dem Host.
Die Komprimierung könnte die Werte etwas hochtreiben, je nachdem was CrystalDiskMark da produziert an Testdaten, aber der Endeffekt inakzeptabel, egal auf welchem Weg wie viel Last zustande kommt: Der Host frisst sich schlagartig mit RAM voll bis der OOM Killer eingreift.

Wenn ich die Last früh genug wegnehme, stoppt ebenfalls das I/O - allerdings überlebt der Host und knabbert Stück für Stück in ca. 100MB/s Schritten den RAM wieder runter, danach geht das I/O in der VM wie gehabt weiter.

Die Problematik lies sich in Windows 10 VMs auf 2 unterschiedlichen Hosts jeweils reproduzieren - sowohl auf pve-no-subscription als auch pvetest.
In allen Fällen wurden VirtIO Block Disks verwendet, mit discard=on und unter Windows wurden der Qemu Guest Agent sowie die virtio Treiber (stable) installiert.

Ich weiß ehrlich gesagt nicht ganz weiter...
Aus einer Linux VM heraus hab ich das noch nicht probiert, das werde ich noch.
Aktuell schaut es so aus, als gäbe es noch ein weiteres Caching Layer das irgendwie durchdreht - aber wo genau das herkommt kann ich nicht sagen.

Die Hosts sind jeweils mit 64 GB DDR4 RAM ausgestattet, einer mit ECC, einer ohne.
Etwaige Details zur Hardware / Software kann ich gerne alles rausgeben, bitte sagt mir was ihr da brauchen könnt, sonst erstreckt sich das hier bald über 50 Seiten...

@AST hat das scheinbar gleiche Phänomen, allerdings etwas "milder", bedingt durch Massen an RAM die das Problem kaschieren / abfedern, bevor es kracht.
Eventuell mag er dazu noch nähere Details zu seinem Setup rausgeben.

Positiv anzumerken ist, dass die häufigen Crashes die meine Tests verursacht haben keinerlei Datenverlust produzierten an den VMs, es kam einmalig zu einem Resilver auf dem HDD Array, allerdings sonst keine Vorkommnisse.
ZFS for the win.

Mein aktueller Workaround, um versehentliche VM Crashes zu vermeiden, ist ein NVMe SLOG auf dem HDD Array und sync=always auf dem Pool.
Damit ist das ganze Konstrukt "benchmark proof" bislang.
Aber natürlich ist das keine Problemlösung, drum bitte ich euch um Mithilfe, vielleicht sind wir da einer Sache auf der Spur...

Könnt ihr bei euch im Labor sowas reproduzieren?
TLDR: Windows VM mit VirtIO Disks und virtio-stable Treibern, ZFS als Storage drunter - ein Schreib Benchmark sollte einen massiven RAM Anstieg auslösen und je nach Menge an RAM auch zum OOM führen.

Allerlei sonstige Infos stell ich gerne zur Verfügung, einfach anfragen was ihr braucht.
Erstmal noch frohe Ostern euch allen!

Viele Grüße
Felix

 

[AST]

Moin,

selbigen Spaß habe ich auch ... irgendwie.
Richtig übel auffällig ist es bei mir geworden, als ich vom PBS ein Backup in PVE schreiben lies.
Der Host wurde unbenutzbar, bzw. die darauf laufenden VMs. Diesen wurden keine IOs mehr zugeschrieben.
Hierbei handelt es sich um Supermicro-Server mit Expanderbackplane, 24 HDDs die als LVM sonst 200MB schreiben/lesen konnten (sequentiell natürlich).

Nachdem der Traffic aus dem PBS aufhörte, war das System noch 30min beschäftig seinen RAM Cache auf die Platten zu bringen.
Der Speicher, vorher paar GB befüllt, wuchs auf 400GB an. Die Hosts haben 1TB RAM zur Verfügung.

"Screenhots" anbei.

Ich knobel schon Ewigkeiten an den Thomas Krenn Maschinen herum, weil das CEPH einfach nicht "aus der Hufe" kommt, IO von 40MB/s seitens VM und IOPS im zweistelligem Bereich. Die Kollegen aus Österreich (Proxmox) und Thomas Krenn suchen mit mir seit 1,5 Jahren nach der Ursache.
Dass das Problem bei ZFS immernoch besteht ist interessant.

Soweit meinen Anteil lose reingeschmissen.

 

[Dunuin]

Ich weiß ehrlich gesagt nicht ganz weiter...
Aus einer Linux VM heraus hab ich das noch nicht probiert, das werde ich noch.
Aktuell schaut es so aus, als gäbe es noch ein weiteres Caching Layer das irgendwie durchdreht - aber wo genau das herkommt kann ich nicht sagen.

Was sagt denn arc_summary bei dir wenn du ordentlich Schreiblast erzeugst? Das sich der ARC bei asynchronen Schreibvorgängen auf Standardeinstellung 50% vom gesamten RAM nimmt und damit dann VMs über OOM abschießt, wenn man nicht 50% vom RAM für ZFS freihält wäre ja normal.

 

[Felix.]

Das sich der ARC bei asynchronen Schreibvorgängen auf Standardeinstellung 50% vom gesamten RAM nimmt und damit dann VMs über OOM abschießt, wenn man nicht 50% vom RAM für ZFS freihält wäre ja normal.

Der ARC sollte anderen Prozessen die RAM brauchen eigentlich nachgeben, genau das passiert auch, wenn ich bare-metal einen Benchmark fahre.

Ich habe auch mal einen Host im "Leerlauf" gehabt, d.h. lediglich eine Windows VM mit 8GB RAM fest reserviert und den Rest frei (~50GB für den ARC problemlos machbar). Selbes Problem, der Verbrauch sprengt den ARC, selbst wenn ich ein festes Limit von bspw. 8GB setze, das wird ignoriert.
Drum bin ich gar nicht sicher ob der ARC hier der Übeltäter ist wirklich.

Was sagt denn arc_summary bei dir wenn du ordentlich Schreiblast erzeugst?

Das lass ich mal aufzeichnen während eines Benchmarks in der VM und lade es dann hoch hier.

 

[Dunuin]

Ich bin auch nicht ganz sicher wo ZFS die Writes im RAM hält. Das alles erst im RAM landet ist ja klar, aber der ARC ist ja eigentlich ein Read-Cache und kein Write-Cache. Selbst bei Sync Writes sollte ja alles im RAM landen, da der ZIL nur als Backup dient, falls die Daten im RAM durch einen Stromausfall verloren gehen. Aber bei Sync Writes wird ja alles linear abgearbeitet und die Last kann dann ja garnicht erst so groß werden.

 

[0xd149e38e]

Da hat jemand bei OpenZfs einen bug erstellt für zfs version 0.8.3 und kernel 5.3.18-3-pve

High unaccounted memory usage #10302
https://github.com/openzfs/zfs/issues/10302

Vielleicht würde es Sinn machen, den Bug zu aktualisieren, wenn der aktuelle Kernel und zfs 2.0.x auch betroffen sind.

 

[Felix.]

Ich habe mir das ein bisschen durchgelesen, das schaut so aus als würden die da generelle "Probleme" bezüglich des ARC besprechen.
Wie gesagt, der OOM lässt sich nur innerhalb einer Windows VM produzieren, nicht auf dem Pool direkt, auch mit größter Gewalt nicht.
Ich hab da 64GB große Benchmarks rüber heizen lassen ohne jeden Effekt, auch mit abgeschalteter Komprimierung um etwaige Verfälschungen dadurch ausschließen zu können.