Hallöchen,
wir haben hier ein etwas seltsames Problem. Vorab einmal unsere Struktur: Wir setzen auf bare-metal Servern Proxmox mit ZFS auf, worauf eine Linux VM mit normalem ext4 läuft. Für die Disk haben wir in Proxmox folgende Settings hinterlegt:
- Cache: Default
- Discard: Aktiv
- IO thread: Aktiv
- SSD emulation: Aktiv
- Async IO: threads
Machen wir nun über den in Proxmox eingebundenen Proxmox Backup Server ein Backup, geht der iowait spürbar extrem nach oben (weit über 20), auf allen Systemen. Also egal welche Hardware, ob AMD oder Intel, egal ob Consumer oder Enterprise oder ob NVMe oder SSD. Hier einmal ein Auszug vom Backup (ab dem bold markierten, geht der iowait los):
Hat oder hatte jemand ähnliche Probleme oder eventuelle Lösungsvorschläge? Wir probierten bereits direkt vor dem Backup, einen fstrim manuell auszuführen, wir dachten erst, dass es tatsächlich half, aber nur initial.
Es handelt sich hierbei übrigens scheinbar nur um den inkrementellen Part, ist noch kein Backup vorhanden, läuft das relativ problemlos.
Der selbe PBS wird auch auf anderen Systemen, ohne ZFS verwendet, da läuft es einwandfrei, ohne iowait bzw. irgendwelchen Einschränkungen. Also unsere einzige Idee ist, dass der PBS ggf. nicht ganz so gut mit ZFS oder unseren Settings oder sonstigem klar kommt und deshalb die VM leidet.
Mit freundlichen Grüßen
Marc âka NothingTV
wir haben hier ein etwas seltsames Problem. Vorab einmal unsere Struktur: Wir setzen auf bare-metal Servern Proxmox mit ZFS auf, worauf eine Linux VM mit normalem ext4 läuft. Für die Disk haben wir in Proxmox folgende Settings hinterlegt:
- Cache: Default
- Discard: Aktiv
- IO thread: Aktiv
- SSD emulation: Aktiv
- Async IO: threads
Machen wir nun über den in Proxmox eingebundenen Proxmox Backup Server ein Backup, geht der iowait spürbar extrem nach oben (weit über 20), auf allen Systemen. Also egal welche Hardware, ob AMD oder Intel, egal ob Consumer oder Enterprise oder ob NVMe oder SSD. Hier einmal ein Auszug vom Backup (ab dem bold markierten, geht der iowait los):
INFO: starting new backup job: vzdump 100 --storage pbs --remove 0 --notes-template '{{guestname}}' --mode snapshot --node root183-managed
INFO: Starting Backup of VM 100 (qemu)
INFO: Backup started at 2023-12-04 19:00:14
INFO: status = running
INFO: VM Name: s1.hostpool.io
INFO: include disk 'scsi0' 'local-zfs:vm-100-disk-0' 380G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: pending configuration changes found (not included into backup)
INFO: creating Proxmox Backup Server archive 'vm/100/2023-12-04T18:00:14Z'
INFO: issuing guest-agent 'fs-freeze' command
INFO: issuing guest-agent 'fs-thaw' command
INFO: started backup task '6a2bf088-876a-42ba-b4e2-4097ac6b770d'
INFO: resuming VM again
[B]INFO: scsi0: dirty-bitmap status: OK (25.9 GiB of 380.0 GiB dirty)
INFO: using fast incremental mode (dirty-bitmap), 25.9 GiB dirty of 380.0 GiB total
INFO: 1% (404.0 MiB of 25.9 GiB) in 3s, read: 134.7 MiB/s, write: 134.7 MiB/s
INFO: 2% (552.0 MiB of 25.9 GiB) in 9s, read: 24.7 MiB/s, write: 24.7 MiB/s
INFO: 3% (812.0 MiB of 25.9 GiB) in 14s, read: 52.0 MiB/s, write: 52.0 MiB/s[/B]
Hat oder hatte jemand ähnliche Probleme oder eventuelle Lösungsvorschläge? Wir probierten bereits direkt vor dem Backup, einen fstrim manuell auszuführen, wir dachten erst, dass es tatsächlich half, aber nur initial.
Es handelt sich hierbei übrigens scheinbar nur um den inkrementellen Part, ist noch kein Backup vorhanden, läuft das relativ problemlos.
Der selbe PBS wird auch auf anderen Systemen, ohne ZFS verwendet, da läuft es einwandfrei, ohne iowait bzw. irgendwelchen Einschränkungen. Also unsere einzige Idee ist, dass der PBS ggf. nicht ganz so gut mit ZFS oder unseren Settings oder sonstigem klar kommt und deshalb die VM leidet.
Mit freundlichen Grüßen
Marc âka NothingTV
Last edited:
