Interrupt Probleme

[Vengance]

Hallo,


Ich führe gerade einige Tests durch, wie sich Proxmox in größeren Setups verhält, wo im Worst case mehrere Aktionen zeitgleich oder mit wenigen Sekunden zeitlicher Versetzung ausgeführt werden.


Folgendes Beispiel, ich habe drei VMs, die im Abstand von wenigen Sekunden alle neu gebaut/ konfiguriert werden sollen.
Dieser Prozess besteht aus folgendem Ablauf:

- Existierende VM wird gestoppt und dann gelöscht
- Template wird geklont
- Setzen der HW Config
- Vergrößern der Disk
- Setzen Cloud Init Config
- Konfigurieren der Firewall
- Start der VM


Ausgeführt wird das über drei separate Background Worker, die eine simultane Ausführung zulassen.


Bei meinen tests bin ich reproduzierbar regelmäßig in Interrupt Probleme geraten.
Anbei ein paar weitere Screenshots.

Beispielsweise kann ich regelmäßig folgende Probleme reproduzieren, wenn im letzten Schritt die VM gestartet werden soll:

2023-11-27T18:53:07.059904+01:00 dev1 pvedaemon[28957]: command 'set -o pipefail && genisoimage -quiet -iso-level 3 -R -V cidata /run/pve/cloudinit/1003/ | qemu-img dd -n -f raw -O raw 'isize=0' 'osize=4194304' 'of=/dev/zvol/rpool/data/vm-1003-cloudinit'' failed: received interrupt
2023-11-27T18:53:07.066633+01:00 dev1 pvedaemon[24593]: <root@pam!api> end task UPID:dev1:0000711D:000477F2:6564D77D:qmstart:1003:root@pam!api: command 'set -o pipefail && genisoimage -quiet -iso-level 3 -R -V cidata /run/pve/cloudinit/1003/ | qemu-img dd -n -f raw -O raw 'isize=0' 'osize=4194304' 'of=/dev/zvol/rpool/data/vm-1003-cloudinit'' failed: received interrupt

generating cloud-init ISO
Warning: sch_htb: quantum of class 10001 is big. Consider r2q change.
TASK ERROR: VM 1007 qmp command 'query-machines' failed - received interrupt

generating cloud-init ISO
command '/usr/bin/kvm --version' failed: received interrupt
TASK ERROR: Detected old QEMU binary ('unknown', at least 3.0 is required)

Ähnliche Interrupt Probleme konnte ich aber auch bei anderen Aktionen auslösen, beispielsweise Stoppen einer VM oder teilweise beim setzen der Config.
Der Syslog zeigt leider keinerlei Auffälligkeiten.

Zwischen dem senden der einzelnen Requests habe ich stets überprüft, dass Proxmox keinen Lock mehr auf die VM hat und kein anderer Task zu dem Zeitpunkt noch läuft bevor der nächste Request gesendet wird.


Übersehe ich hier irgendwas?

 

[sb-jw]

Hast du denn bereits ausschließen können, dass das Problem mangels Hardware-Ressourcen / Kapazitäten auftritt? Gerade in größeren Clustern sollten ja entsprechende Ressourcen massenweise vorhanden sein, so dass sich gewisse Probleme vielleicht auch einfach mit Hardware erschlagen lassen. Vielleicht sind deine Worker auch nicht optimal gescripted oder du eröffnest immer wieder neue API Verbindung statt eine bestehende zu nutzen etc. pp.

Ich finde es zumindest immer schwierig in den Raum zu werfen, dass Produkt X oder Y keine Performance bringt, man zeitgleich aber keine Details zu seinem Setup, Scripten etc. gibt. Auf der Ebene ist es zumindest für beide Seiten schwer hier sachliche Argumente zu finden.

 

[Vengance]

Hi,

Die Hardware sollte eigentlich ausreichend dimensioniert sein, meine Testumgebung läuft hier auf einem EPYC 7542 System mit massig RAM und Datacenter NVMEs.

Vielleicht hatte ich den Thread etwas ungünstig formuliert, es kann natürlich sehr gut sein, dass die Ursache nicht bei Proxmox an sich liegt.
Ich versuche jede Option abzuwägen, es lässt mich nur generell nichtmehr los wo konkret hier das Bottleneck ist.

Vielleicht sehe ich auch gerade den Wald vor lauter Bäumen nichtmehr.

root@dev1:~# pveversion -v
proxmox-ve: 8.1.0 (running kernel: 6.5.11-4-pve)
pve-manager: 8.1.3 (running version: 8.1.3/b46aac3b42da5d15)
proxmox-kernel-helper: 8.0.9
pve-kernel-5.15: 7.4-8
proxmox-kernel-6.5.11-4-pve-signed: 6.5.11-4
proxmox-kernel-6.5: 6.5.11-4
pve-kernel-5.15.131-1-pve: 5.15.131-2
pve-kernel-5.15.116-1-pve: 5.15.116-1
pve-kernel-5.15.107-1-pve: 5.15.107-1
pve-kernel-5.15.102-1-pve: 5.15.102-1
ceph-fuse: 16.2.11+ds-2
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx7
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.0
libproxmox-backup-qemu0: 1.4.0
libproxmox-rs-perl: 0.3.1
libpve-access-control: 8.0.7
libpve-apiclient-perl: 3.3.1
libpve-common-perl: 8.1.0
libpve-guest-common-perl: 5.0.6
libpve-http-server-perl: 5.0.5
libpve-network-perl: 0.9.4
libpve-rs-perl: 0.8.7
libpve-storage-perl: 8.0.5
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 5.0.2-4
lxcfs: 5.0.3-pve3
novnc-pve: 1.4.0-3
proxmox-backup-client: 3.0.4-1
proxmox-backup-file-restore: 3.0.4-1
proxmox-kernel-helper: 8.0.9
proxmox-mail-forward: 0.2.2
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.1.3
pve-cluster: 8.0.5
pve-container: 5.0.8
pve-docs: 8.1.3
pve-edk2-firmware: 4.2023.08-2
pve-firewall: 5.0.3
pve-firmware: 3.9-1
pve-ha-manager: 4.0.3
pve-i18n: 3.1.2
pve-qemu-kvm: 8.1.2-4
pve-xtermjs: 5.3.0-2
qemu-server: 8.0.10
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.0-pve3

 

[sb-jw]

Also du hast derzeit davon eine Node am laufen und erstellst auch direkt dort die weiteren VMs und hast keine Testumgebung in PVE eingerichtet auf der du testest?
Grundsätzlich gebe ich dir recht, es ist potente Hardware. Jetzt kommt aber mein "aber", in einer größeren Umgebung sprechen wir ja auch von mehreren Nodes, nicht von einer. Hier würde man ja auch die API Requests auf die Nodes verteilen und nicht alles auf ein Ziel jagen. Alleine dieser Umstand könnte ja bereits für eine Verbesserung sorgen.

Bzgl. der API Requests oder der Scripte ist es ja oftmals so, dass diese unsauber und nicht ganz durchdacht erstellt wurden. Viel Performance verschenkt man ja bereits damit, dass man nicht eine Verbindung öffnet und auf dieser Requests abschickt sondern jedes mal eine neue aufbaut. Ich würde ein solches Script auch so schreiben, dass z. B. alle 5 - 10 Sekunden geprüft wird ob ein Vorgang abgeschlossen ist und nicht jede Sekunde. Damit hast du oftmals automatisch eine "cooldown" Phase eingebaut, auch das könnte für Entspannung sorgen.

Hast du denn schon feststellen können, dass deine Worker ggf. versuchen die selben Ressourcen zu allokieren? Also Stichwort Race Condition.

Interessant wäre an der Stelle vielleicht auch zu sehen, welche Last in dem Moment auf dem System entsteht um dadurch womöglich zu erkennen, dass vlt. das File Limit eingreift und deshalb gewisse Aktionen nicht mehr gehen oder, dass die I/O gerade massiv abgeraucht ist, ein I/O Delay entstanden ist.

Ich selbst nutze auch die API und habe parallel 5 Worker laufen, welche sich die Jobs aus den Warteschlangen greifen und dann abarbeiten. Da ich aber auch noch den produktiven Betrieb dadrauf am laufen habe, bin ich auch damit zufrieden, wenn eine VM in 40 Sekunden deployed ist statt in 30 Sekunden. Es ist hierbei auch immer die Frage, welches Ziel du verfolgst, ob dein Szenario in der Realität tatsächlich relevant wird oder du es eigentlich so gar nicht brauchst.

Tritt denn das Problem tatsächlich immer auf wenn du diese drei VMs im gleichen Schema neu erstellst, oder ist eher so, dass z. B. jeder 3 Versuch fehlschlägt? Nimmt denn in dem Moment die API noch befehle entgegen oder ist die auch ausgestiegen?

 

[Vengance]

> Also du hast derzeit davon eine Node am laufen und erstellst auch direkt dort die weiteren VMs und hast keine Testumgebung in PVE eingerichtet auf der du testest?

Die Hardware ist noch nicht im Produktivbetrieb daher kann ich diese gerade als Testumgebung missbrauchen. Ich habe noch andere Testumgebungen, aber die laufen auf schwächerer Hardware, daher wohl nicht wirklich für solch einen load test geeignet.


> Hast du denn schon feststellen können, dass deine Worker ggf. versuchen die selben Ressourcen zu allokieren? Also Stichwort Race Condition
Yes, deswegen wird vor jedem request explizit validiert, dass auf der VM kein lock ist und kein anderer Task noch läuft. Ansonsten wird auf basis eines backoffs gewartet, bis das Szenario erfüllt ist ohne hier zu viele requests zu senden.


> Interessant wäre an der Stelle vielleicht auch zu sehen, welche Last in dem Moment auf dem System entsteht um dadurch womöglich zu erkennen, dass vlt. das File Limit eingreift und deshalb gewisse Aktionen nicht mehr gehen oder, dass die I/O gerade massiv abgeraucht ist, ein I/O Delay entstanden ist.

Sowohl Ressourcen Nutzung als auch File limit sehen gut aus. Auch der IO Delay steigt nicht über 10%


> Tritt denn das Problem tatsächlich immer auf wenn du diese drei VMs im gleichen Schema neu erstellst, oder ist eher so, dass z. B. jeder 3 Versuch fehlschlägt? Nimmt denn in dem Moment die API noch befehle entgegen oder ist die auch ausgestiegen?

Nein es tritt so mit geschätzt 20-30%iger Wahrscheinlichkeit auf.
Die API ist dennoch weiterhin erreichbar.


Ich werde morgen das ganze auf einem komplett frischen System testen um hier irgendwelche Probleme durch das vorherige pve 7.x auf 8.x update auszuschließen.

Danke jedenfalls schonmal für den Input

 

[Falk R.]

Ein I/O Delay von 10% bei einer solchen Hardware, habe ich noch nicht gesehen.
Der größte Cluster mit 11 Nodes und 700 VMs kommt nie über 3% Delay. Und das inclusive Ceph.
Bei so ein paar API Requests sollte der Delay nicht hochgehen, außer du deployst mal eben 50 VMs auf einem Knoten.

Ist das jetzt ein Single Knoten oder ein Cluster? Wenn das ein Cluster ist, über welche Leitung geht da Corosync?
Stichwort Clusterfilesystem Sync.

 

[Vengance]

Ein I/O Delay von 10% bei einer solchen Hardware, habe ich noch nicht gesehen.
Der größte Cluster mit 11 Nodes und 700 VMs kommt nie über 3% Delay. Und das inclusive Ceph.
Bei so ein paar API Requests sollte der Delay nicht hochgehen, außer du deployst mal eben 50 VMs auf einem Knoten.

Ist das jetzt ein Single Knoten oder ein Cluster? Wenn das ein Cluster ist, über welche Leitung geht da Corosync?
Stichwort Clusterfilesystem Sync.

Sorry, Ich korrigiere, das maximum waren 3,89% peak.
Habe gerade im Monitoring nochmal nachgeschaut, da mir das auch ein wenig hoch vorkam. Habe ich vielleicht aus dem Augenwinkel falsch abgelesen.

Das Testsystem ist ein Single Knoten mit ZFS.

 

[Falk R.]

Was für Enterprise NVMe sind das? U.2 oder m.2?

 

[Vengance]

2x Samsung PM9A3 U.2 angebunden via PCIe Gen4

 

[Falk R.]

Hast du die C-States im BIOS deaktiviert?
Eventuell läufst du in die CPU Stalls wenn runter oder hoch getaktet wird. Der Stromsparmodus macht im Datacenter die Latenzen regelmäßig kaputt.