PVE9 | PBS 4: VMs haben 100% CPU-Last nach Backupvorgang

W

-wastl

Member
Nov 23, 2022
12
2
8
Hallo zusammen,
seit den Upgrades meiner Proxmox-Server auf PVE9 und PBS4 tritt jede Nacht dasselbe Problem auf:
Zwei der VMs laufen ab dem Backup-Prozess mit voller CPU-Auslastung. Reboot der VMs bringt keine Besserung. Erst ein Reboot des Hostsystems lässt die VMs wieder normalisieren.
Es betrifft immer dieselben beiden VMs. Auf diesen läuft Debian 13 und jeweils ein Docker-Stack. LXCs sind keine betroffen, andere VMs ebenfalls nicht, obwohl es weitere identisch konfigurierte (Debian 13, Docker) gibt.
Die Updates laufen ganz normal zeitgesteuert nachts via Proxmox Backup Client auf einen Proxmox Backup Server (zweite Maschine). Auch werden die Backups erfolgreich vollständig abgeschlossen.
Da ich unmöglich jeden Tag das Hostsystem rebooten kann bin ich für jeden Tipp dankbar, was ich prüfen kann oder ob es hier bereits ein bekanntes Problem gibt, an dem gearbeitet wird?
Vielen Dank im Voraus
 
ok, damit söcheine ich wohl alleine zu sein. hab auch keine beschwerden in der richtung gelesen bisher.
leider weiß ich nicht so recht wie ich der sache auf den grund gehen könnte.
 
Beide VMs wurden via CloudInit aufgesetzt und sind identisch konfiguriert, ursprünglich mit Debian 12. Das Upgrade auf Debian 13 erfolgte bereits vor dem Upgrade von Proxmox. Bis dahin lief noch alles wie gewohnt. Nach dem Proxmox-Upgrade kam es dann zu dem merkwürdigen verhalten.
Gleichzeitig sind diese beiden VMs nicht die einzigen welche aus demselben CloudInit-Image erzeugt wurden. Die anderen machen aber keine Probleme.

Bash: 
agent: 1
balloon: 1024
boot: order=ide2;scsi0;net0
cipassword: ###
ciuser: ###
cores: 4
cpu: host,flags=+aes
ide0: local-zfs:vm-104-cloudinit,media=cdrom,size=4M
ide2: none,media=cdrom
ipconfig0: ip=dhcp
memory: 4096
meta: creation-qemu=9.2.0,ctime=1746782411
name: Paperless
net0: virtio=###,bridge=vmbr0,firewall=1
numa: 1
onboot: 1
ostype: l26
parent: ###
scsi0: local-zfs:vm-104-disk-0,discard=on,iothread=1,size=16G,ssd=1
scsihw: virtio-scsi-single
serial0: socket
smbios1: uuid=###
sockets: 1
sshkeys: ssh-###
vga: serial0
vmgenid: ###

Bash: 
agent: 1
balloon: 512
boot: order=ide2;scsi0;net0
cipassword: ###
ciuser: ###
cores: 4
cpu: host,flags=+aes
ide0: local-zfs:vm-302-cloudinit,media=cdrom,size=4M
ide2: none,media=cdrom
ipconfig0: ip=dhcp
memory: 4096
meta: creation-qemu=9.2.0,ctime=1746782411
name: Immich
net0: virtio=###,bridge=vmbr0,firewall=1,tag=150
numa: 1
onboot: 1
ostype: l26
parent: ###
scsi0: local-zfs:vm-302-disk-0,discard=on,iothread=1,size=16G,ssd=1
scsi1: local-zfs:vm-302-disk-1,discard=on,iothread=1,size=300G,ssd=1
scsihw: virtio-scsi-single
serial0: socket
smbios1: uuid=###
sockets: 1
sshkeys: ssh-###
vga: serial0
vmgenid: ###
 
Heute konnte ich außerdem beobachten, dass das Symptom auch auftritt wenn eine andere VM ein Backup fährt. Also wenn eine dritte VM backuped lasten die genannten beiden anderen total aus bis zum Rebott des Hosts.
 
Hallo, die CPU-Auslastung bei den betroffenen VMs nach einem Backup ist ein bekanntes Problem, das häufig durch Prozesse innerhalb der VMs im Zusammenspiel mit den Proxmox-Upgrades verursacht wird. Oft liegt es an Dateisystem-Operationen oder I/O-intensiven Tasks, die vom Backup-Vorgang getriggert werden und nicht korrekt beendet werden. Da ein Reboot der VMs allein nicht hilft und die volle Auslastung auch durch Backups anderer VMs ausgelöst wird, deutet dies auf einen Konflikt zwischen den VMs und dem Host-Kernel oder den QEMU-Prozessen hin. Ein bekanntes Problem, das in der Vergangenheit oft mit ähnlichen Symptomen auftrat, war die Kombination von virtio-scsi-single, discard=on (TRIM/UNMAP) und dem QEMU I/O-Thread, insbesondere bei bestimmten Linux-Kernel-Versionen.

Da Sie die Upgrades auf Proxmox VE 9 und Proxmox Backup Server 4 durchgeführt haben, ist es wahrscheinlich, dass Änderungen an den Treibern, Kernel-Versionen oder der QEMU-Implementierung das Verhalten Ihrer spezifischen VMs beeinflussen. Hier sind die wichtigsten Punkte, die Sie überprüfen können:
  • Deaktivieren von I/O-Threads und Discard: Deaktivieren Sie testweise die Optionen iothread=1 und discard=on in der Konfiguration der betroffenen VMs. Diese Einstellungen können unter bestimmten Bedingungen zu unerwünschten I/O-Spitzen und damit zu hoher CPU-Auslastung führen. Bei VMs mit ZFS-Backends ist discard nicht zwingend notwendig, da ZFS die Blöcke ohnehin effizient verwaltet. Ändern Sie die Konfiguration der VMs von scsi0: ...,discard=on,iothread=1 auf scsi0: ...,iothread=0,discard=off.
  • VirtIO SCSI-Treiber: Das Problem könnte mit dem verwendeten SCSI-Controller zusammenhängen (scsihw: virtio-scsi-single). Versuchen Sie, den Controller-Typ auf virtio-scsi (ohne -single) oder VirtIO Block umzustellen. virtio-scsi-single ist oft eine gute Wahl, aber in manchen Konfigurationen kann es zu Problemen kommen. Testen Sie eine alternative Konfiguration.
  • Guest-Agent und QEMU: Da das Problem auch auftritt, wenn andere VMs gesichert werden, könnte es sich um einen Konflikt im Zusammenspiel zwischen dem Proxmox QEMU Guest Agent (agent: 1) und den neuen QEMU-Prozessen handeln. Stellen Sie sicher, dass der Guest Agent in den betroffenen VMs auf dem neuesten Stand ist. Alternativ könnten Sie den Agenten testweise deaktivieren, um zu sehen, ob das Problem weiterhin besteht.
  • Linux-Kernel: Ihre VMs laufen mit Debian 13. Vergewissern Sie sich, dass der Kernel in den VMs aktuell ist. Manchmal beheben Kernel-Updates Probleme, die durch neue VirtIO-Treiber oder QEMU-Funktionen auf der Host-Ebene verursacht werden. Ein Downgrade des Host-Kernels (Proxmox VE) kann eine vorübergehende Lösung sein, bis ein Patch verfügbar ist.
 
  • Like
Reactions: -wastl
Bu66as said:
Hallo,
Click to expand...
Ich plädiere bei solchen Texten für eine "LLM=xyz"-Erwähnung. Ich kann das nicht erkennen und nicht belegen, aber genau das ist ein zunehmendes Problem - in meinen Augen...)
 
  • Like
Reactions: Johannes S
Ob ich nun Hallo oder Hi schreibe, obliegt doch mir, wo ist das Problem hier?
 
Bu66as said:
Ob ich nun Hallo oder Hi schreibe, obliegt doch mir, wo ist das Problem hier?
Click to expand...
Es ging nicht um das einzelne Wort sondern um den ganzen Post, den ich aber nicht komplett zitieren wollte. ;-)

Stammt der Text in #6 im wesentlich von einem Chatbot? Falls ja würde ich gerne einen Hinweis darauf sehen. Das ist nur eine Bitte...
 
  • Like
Reactions: pixelpeter and Johannes S
Ja, ich habe meine Informationen und Formulierungen mit einem LLM verbessert, um den Text klarer, besser lesbar, präziser oder strukturierter zu gestalten, daher ist es aber kein reine generierte Antwort von einem LLM, sondern nur ein Korrektor, der einen Text überarbeitet.
 
LLMs machen Texte weder klarer, noch besser, präziser oder strukturierter. Ihre Ergüsse sind aber zuverlässig als ki-generiert erkennbar und sorgen bei mir dafür sie ( samt Autoren ) zu ignorieren. Wer zu faul ist Probleme und ihre Verwendung in eigenen Worten zu beschreiben, bei dem bin ich zu faul zum lesen und antworten.
 
  • Like
Reactions: UdoB
bin trotzdem dankbar mal ein paar hinweise bekommen zu haben, was ich ausprobieren kann. egal wer das wie verfasst hat. danke dafür.
 
  • Like
Reactions: UdoB
You must log in or register to reply here.
Top Bottom