How to crash ProxMox7 VE

[tesme13]

Hi
ich wollte mal fragen ob das jemand bestätigen kann.

Setup:
HW: Xeon X3440, 1TB SSD SATA, 16 GB MEM
SW: Proxmox VE 7, ZFS , alles nur auf der lokalen Disk installiert. Keine speziellen Optionen ausgewählt.

VM: Windows 10 21H1, 4GB MEM, 64GB HD, letzte Patche und ATTO Disk Benchmark, Virtio disc und Netz, kein Balloon treiber. (Mit Balloon TReiber gibt es den gleichen Effekt)

Einfach mal den Diskbenchmark laufen lassen (Bild1) und dann beginnt mit einem mal der Kernel die Prozesse zu killen und die Kiste steht dann (Bild2).

Gleiches setup aber ext4 als FS bei der installation gewählt. Alles geht.

 

[t.lamprecht]

Hi,

Im zweiten Bild sieht man, dass der Out-Of-Memory (OOM) Killer zuschlagen muss da zu dem Zeitpunkt nicht genug verfügbarer Arbeitsspeicher vorhanden ist.

Wurde evtl. der Arbeitsspeicher "overcommitet", also mehr insgesamt zugewiesen als auf der Maschine verfügbar ist?

Ein Diskbenchmark kann schon mal die Anforderungen an RAM erhöhen, auch QEMU selbst hat ja beim virtualisieren etwas Overhead. Also, wie viele VMs laufen auf den Host und wie viel RAM ist denen in Summe zugewiesen?

Virtio disc

VirtIO Block oder VirtIO SCSI?

 

[tesme13]

Hi
bezgl Arbeitspeicher: Die Kiste hat 16GB und die EINE VM hat 4GB zugewiesen. Sonst läuft nix. Also das OS hat 12GB Speicher.
Mit Ext4 läuft das auch ohne Porbleme.
Ich nutze den Virtio SCSI treiber.

Aber das ist hier nicht das Thema. Es ist tötlich für eine Virtualisierungsumgebung wenn eine VM in der ein Anwender irgendwas laufen lassen kann den gesamten HyperVisor crashen kann.

Eigentlich dachte ich mittels der Replication könnte man ganz nett ein Cold Standby aufsetzen. Aber das geht ja nur mit ZFS.

Gruss
Wieland

 

[t.lamprecht]

bezgl Arbeitspeicher: Die Kiste hat 16GB und die EINE VM hat 4GB zugewiesen. Sonst läuft nix. Also das OS hat 12GB Speicher.

Na ja, das OS hat 4 GiB den bei ZFS wird die Hälfte des totalen Arbeitspeichers (also 8 GiB) per Default für den ZFS ARC verwendet..

Evtl. den ARC mal reduzieren: https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#sysadmin_zfs_limit_memory_usage

Aber das ist hier nicht das Thema. Es ist tötlich für eine Virtualisierungsumgebung wenn eine VM in der ein Anwender irgendwas laufen lassen kann den gesamten HyperVisor crashen kann.

Daher ist das ja genau das Thema, wenn OOM zuschlägt, schaut man sich mal den RAM an, denn wenn User overcommiten würden kann der Kernel ja nicht Wunder wirken

Für mehr Analyse über was da wirklich los war, bräuchte man den vollen Syslog bzw. das Journal, idealerweise in Textform...

 

[tesme13]

Hi
das mit den Logs ist kein Thema.

Welche Files ?
Plain vom Linux oder über die Oberfläche von PVE runterziehen ? --> ich habe mal in der Oberfläche unter syslog die Meldungen kopiert. Passiert ist es gestern abend. Da sieht man ja dass um ung. 20:10 der Rechner neu gestartet wurde.
Wohin schicken/posten ? --> ich habs hier mal angehängt.

Laut der ZFS page sollte Speicher aber kein Thema sein.

50% Speicher default bei ARC == 8 GB
1 TB SSD --> 1 GB
Summe 9 GB für ARC
4 GB für die VM
bleiben 3 GB für Linux.

P.S.: Versteht mich nicht falsch. Ich finde das System toll. Aber dass eine User/eine VM ein System crashen kann ist gefährlich wenn man das im Produktiveinsatz nehmen will.


Danke
Wieland

 

[tesme13]

Hi
ich habe mal mit arcstat geschaut wie es der Kiste geht. Und ich würde sagen hier passt Doku und Realität nicht zusammen.
In der Doku steht was von 50% des total MEM und 1 GB je TB speicher. Aber hier denkt sich ARC : Gleich mal 13 GB von 16 GB nehmen was weiss ja nicht was kommt . Erwarten sollte man 9 GB für ARC Cache.

root@pve:~# arcstat 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  size     c  avail
07:54:58     0     0      0     0    0     0    0     0    0  280M  4.0G    13G
07:55:01   297     0      0     0    0     0    0     0    0  280M  4.0G    13G
07:55:04     1     0      0     0    0     0    0     0    0  280M  4.0G    13G
07:55:07    39     0      0     0    0     0    0     0    0  280M  4.0G    13G
 
c : ARC target size
avail : ARC available memory

 

[t.lamprecht]

Welche Files ?
Plain vom Linux oder über die Oberfläche von PVE runterziehen ?
Wohin schicken/posten ?

Wäre zwar übers Proxmox VE Web-Interface möglich, da alles zu kopieren ist aber potenziell mühsam, also besser am host folgenden Befehl ausführen (nimmt nur den Log vom aktuellen boot!)

journalctl -b > "journal-$(date -Is).txt"

# oder komprimieren falls es sonst zu groß wird:
journalctl -b  | zstd >"journal-$(date -Is).txt.zst"

und hier im Thread als Anhang raufladen

bleiben 3 GB für Linux.

4 GiB, die 1 GiB pro TiB ist eine Empfehlung und wird nicht automatisch drauf gegeben.
In jedem Fall aber offensichtlich zu wenig unter Last.. Wie gesagt, evtl. den ARC reduzieren, 3 GiB sollte bei dem System genug sein. Mit ext4 ist der ARC nicht da und dann gibt's halt RAM zur Genüge.

 

[t.lamprecht]

In der Doku steht was von 50% des total MEM und 1 GB je TB speicher

Nein, in der Doku steht (1:1 Zitat):

ZFS uses 50 % of the host memory for the Adaptive Replacement Cache (ARC) by default

Also 50% default wird reserviert, was der ARC grad damit macht ist was anderes, die stehen aber für den Rest des Systems nicht zur verfügung.

Was wir dann weiter Dokumentieren ist:

As a general rule of thumb, allocate at least 2 GiB Base + 1 GiB/TiB-Storage

D.h., für den Admin ist als Richtwert für eine untere Schwelle die noch OK is (über mehr wird sich ZFS nicht beklagen ) 2 GiB + 1 GiB/TiB-Storage, daher bei deinem System 3 GiB, weil 2 GiB basis und ein TiB Storage -> plus 1 GiB..

 

[tesme13]

Wäre zwar übers Proxmox VE Web-Interface möglich, da alles zu kopieren ist aber potenziell mühsam, also besser am host folgenden Befehl ausführen (nimmt nur den Log vom aktuellen boot!)

journalctl -b > "journal-$(date -Is).txt"

# oder komprimieren falls es sonst zu groß wird:
journalctl -b  | zstd >"journal-$(date -Is).txt.zst"

und hier im Thread als Anhang raufladen



4 GiB, die 1 GiB pro TiB ist eine Empfehlung und wird nicht automatisch drauf gegeben.
In jedem Fall aber offensichtlich zu wenig unter Last.. Wie gesagt, evtl. den ARC reduzieren, 3 GiB sollte bei dem System genug sein. Mit ext4 ist der ARC nicht da und dann gibt's halt RAM zur Genüge.

Ich gönne dem system mal 8 GB und lasse das noch mal laufen. Mal sehen ob es dann nicht mehr hängt.
Man sollte aber die vorsichtshalber in der defaultconfig den Parameter setzen und nicht hoffen wird schon gehen.

 

[tesme13]

Hi
irgendwie würde ich sagen das war es nicht.
Habe den Cache drastisch runtergedreht.
root@pve:~# cat /sys/module/zfs/parameters/zfs_arc_min cat /sys/module/zfs/parameters/zfs_arc_max 107374 419843
und ja ich habe die Ramdisk neu gemacht.

Das einzige was passiert ist das die Kiste länger durchhält.

Noch Ideen ?
Gruss
Wieland

 

[t.lamprecht]

Wäre zwar übers Proxmox VE Web-Interface möglich, da alles zu kopieren ist aber potenziell mühsam, also besser am host folgenden Befehl ausführen (nimmt nur den Log vom aktuellen boot!)

journalctl -b > "journal-$(date -Is).txt"

# oder komprimieren falls es sonst zu groß wird:
journalctl -b | zstd >"journal-$(date -Is).txt.zst"

und hier im Thread als Anhang raufladen

 

[Dunuin]

root@pve:~# cat /sys/module/zfs/parameters/zfs_arc_min cat /sys/module/zfs/parameters/zfs_arc_max 107374 419843

Das wären dann 107-419 KB. Laut deinen Screenshots nutzt dein ARC weiterhin einige GBs. Also versuch mal den ARC auf sinnvolle Limits zu setzen (einige GB statt KB) sonst wird da ZFS einfach deine Einstellungen ignorieren und weiter mit den Standardwerten arbeiten:

In case your desired zfs_arc_max value is lower than or equal to zfs_arc_min (which defaults to 1/32 of the system memory), zfs_arc_max will be ignored unless you also set zfs_arc_min to at most zfs_arc_max - 1.

Außerdem musst du dein initramfs neu bauen lassen und den Host rebooten, damit die ZFS Einstellungen wirklich übernommen werden (update-initramfs -u && reboot now).

Danach am besten mal über arc_summary gucken was da nun für Limits benutzt werden und wie die aktuelle tatsächliche ARC Größe ist.

 

[Falk R.]

Oder lass bei der kleinen Kiste ZFS einfach sein. Leg lieber Wert auf ein vernünftiges backup.

 

[tesme13]

Oder lass bei der kleinen Kiste ZFS einfach sein. Leg lieber Wert auf ein vernünftiges backup.

Wie soll dies Aussage hier helfen ?

 

[tesme13]

Das wären dann 107-419 KB. Laut deinen Screenshots nutzt dein ARC weiterhin einige GBs. Also versuch mal den ARC auf sinnvolle Limits zu setzen (einige GB statt KB) sonst wird da ZFS einfach deine Einstellungen ignorieren und weiter mit den Standardwerten arbeiten:

Außerdem musst du dein initramfs neu bauen lassen und den Host rebooten, damit die ZFS Einstellungen wirklich übernommen werden (update-initramfs -u && reboot now).

Danach am besten mal über arc_summary gucken was da nun für Limits benutzt werden und wie die aktuelle tatsächliche ARC Größe ist.

Hi
der Wert den ich hier poste war nur das Ende der Fahnenstange ich bin diverse Werte durchgegangen. 8GB/4GB/2GB/... und der einzige Effekt war das es länger gebraucht hat bis es abraucht.
Da ARC_MIN kleiner ist als ARC_MAX sollte es bei einer korrekten Imlementierung nicht ignoriert werden.
Und das man Neubooten muss dachte ich wäre wohl klar.

ich werde Morgen mal wieder zurück auf 4GB gehen und dann die Logs hochladen.



Gruss

 

[tesme13]

Hi
anbei das log.
Ich habe in der ZFS folgendes eingestellt.
Damit kann ich einmal den Test einmal fahren und beim 2ten mal crashed die Kiste.

root@pve:~# more /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=4294967296
options zfs zfs_arc_min=1073741824
options zfs zfs_prefetch_disable=1

 

[Dunuin]

Umd was sagt da dann dein arc_summary und free -h auf dem host?

 

[tesme13]

Umd was sagt da dann dein arc_summary und free -h auf dem host?

zu welchen Zeitpunkten ?

Angehängt der Zustand wenn die Kiste keine VM am laufen hat.

 

[tesme13]

Hi
anscheinend ist dies kein Thema mehr.
Naja für mich schon.
Habe nun mal das ganze mit eine HP DL360e (2x Xeon CPU E5-2450L 8/16 Core, 48GB mem ) ausprobiert und man kann den oom zum zuschlagen kriegen wenn man der VM 40GB gibt. Also "nur" 8 GB für das OS lässt.
Wobei ZFS immer nur noch 4GB belegen darf.

root@pve:~# more /etc/modprobe.d/zfs.conf options zfs zfs_arc_max=4294967296 options zfs zfs_arc_min=1073741824 options zfs zfs_prefetch_disable=1

Bei der Konfig wird nicht die ganze Kiste in den Abgrund gezogen sondern "nur" die VM.

[16617.821828] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=rrdcached.service,mems_allowed=0-1,global_oom,task_memcg=/qemu.slice/100.scope,task=kvm,pid=445982,uid=0 [16617.822020] Out of memory: Killed process 445982 (kvm) total-vm:44771332kB, anon-rss:43018316kB, file-rss:2332kB, shmem-rss:4kB, UID:0 pgtables:85044kB oom_score_adj:0 [16618.678631] oom_reaper: reaped process 445982 (kvm), now anon-rss:0kB, file-rss:64kB, shmem-rss:4kB


P.S.: Bin in der Zwischenzeit auf PVE 7.1. Gleiches Verhalten wie bei PVE 7.0.

root@pve:~# pveversion pve-manager/7.1-5/6fe299a0 (running kernel: 5.13.19-1-pve)