Sehr hoher IO-Delay bei qmrestore

[Ronny]

Hallo,

auf sämtlichen Proxmox-Servern beobachte ich seit längerem einen sehr hohen IO-Delay (20-30) wenn ein VM-Restore läuft - von NFS-Share auf ISCSI-LVM. Wenn der Restore auf das Lokale LVM läuft ist der IO-Delay wesentlich geringer (3-5).

Das hat teilweise krasse Auswirkungen, sodass andere VMs auf dem ISCSI Laufwerk hängen bleiben usw.

vzdump kann man anpassen (bwlimit, ionice, etc.) - geht das auch irgendwie mit qmrestore?


Danke schonmal im voraus für tips.

pve-kernel-4.4.98-5-pve

 

[HBO]

Gleiches wie bei mir: https://forum.proxmox.com/threads/l...e-unterschied-bei-einem-backup-restore.40891/
Betrifft wohl einige Setups.

 

[Deleted member 34654]

Oder doch das von mir und anderen angesprochen Thema. Aber das wird ja einfach ignoriert wie bei den ganz großen.

Gruß

Markus

@tom bitte löschen kennst dich ja damit aus.

 

[tom]

Oder doch das von mir und anderen angesprochen Thema. Aber das wird ja einfach ignoriert wie bei den ganz großen.

Gruß

Markus

@tom bitte löschen kennst dich ja damit aus.

Nein, das wird nicht ignoriert, bitte unterlasse diese schlicht falschen Unterstellungen.

 

[HBO]

Mich persönlich würde es freuen, nachdem es zu diesem "qmrestore io" Thema doch einige Anfragen gibt, vom Proxmox Staff in einer der vielen Anfragen entweder eine Bestätigung des Problems mit angekündigter Problemlösung, ein Workaround oder gar schon mögliche Lösung präsentiert zu bekommen.

 

[wolfgang]

Es gibt einen Bugzilla Eintrag für diesen Feature Request.
https://bugzilla.proxmox.com/show_bug.cgi?id=460

Ich werde es mir anschauen.

 

[HBO]

Verständnisfrage:
Ich habe in vzdump.conf ein bwlimit von 60000 eingetragen, die Backups laufen aber nur mit 30MB/s. Habe ich einen Denkfehler oder sollten hier knapp 60MB/s erreicht werden?

Vielen Dank für die Prüfung zwecks qmrestore. Daumen hoch.

 

[wolfgang]

Ein Limit ist ja nur ein MAX und wenn z.B. das Komprimieren nicht schnell genug ist oder die Platten dann hilft Dir das Limit auch nicht es schneller zu machen.
Was auch noch ist wir limitieren vor dem Komprimieren.

 

[Deleted member 34654]

Wir haben das gleiche Problem, 10g Netzwerk und nur Max 40mb/s aber glaubt uns ja keiner. Kein ha nutzbar da nach Backup die io nicht mehr runter geht = v5 nicht nutzbar für Unternehmen.

 

[martin]

Wir haben das gleiche Problem, 10g Netzwerk und nur Max 40mb/s aber glaubt uns ja keiner. Kein ha nutzbar da nach Backup die io nicht mehr runter geht = v5 nicht nutzbar für Unternehmen.

40 mb/s beim Restore?

Bitte posten dein gesamtes Restore log, inkl. Beschreibung des Zielstorage.

 

[HBO]

Also wenn ich das bwlimit weg lasse bzw einfach eine 0 dran hänge bekomme ich Transferraten von 300mb/s (im Falle von vzdump). Aber ich denke anderes Thema hierfür?

 

[wolfgang]

Wie schon gesagt wir limitieren vor dem Komprimieren.
Probier bitte mal ohne Komprimieren oder ist das schon ohne?

 

[HBO]

Ich werde das mal testen, das ist mit aktivem LZO.

PS: Habe mit 10G Netzwerk kein Problem, aber auch kein richtigen HA Cluster im Einsatz. Problem besteht halt dann nur in der hohen IO durch qmrestore.

 

[HBO]

So und hier die Tests mit verschiedenen "bwlimit" Werten (was mich nun wundert das der Speed bei 240000 auf einmal passt), ohne Komprimierung und ansonsten Standard Einstellungen.

Spoiler: bwlimit 60000

INFO: starting new backup job: vzdump 101 --mode stop --storage local --compress 0 --remove 0 --node proxnode3
INFO: Starting Backup of VM 101 (qemu)
INFO: status = stopped
INFO: update VM 101: -lock backup
INFO: backup mode: stop
INFO: bandwidth limit: 60000 KB/s
INFO: ionice priority: 7
INFO: VM Name: ts.tks-sicherheit.com
INFO: include disk 'scsi0' 'local-zfs:vm-101-disk-1' 100G
INFO: creating archive '/var/lib/vz/dump/vzdump-qemu-101-2018_01_30-12_01_34.vma'
INFO: starting kvm to execute backup task
INFO: started backup task 'd09e4598-e885-4c5d-9f78-d65d70e370e2'
INFO: status: 0% (92405760/107374182400), sparse 0% (37449728), duration 3, read/write 30/18 MB/s
INFO: status: 1% (1078067200/107374182400), sparse 0% (311779328), duration 35, read/write 30/22 MB/s
INFO: status: 2% (2149974016/107374182400), sparse 0% (361734144), duration 70, read/write 30/29 MB/s
INFO: status: 3% (3225419776/107374182400), sparse 0% (392933376), duration 105, read/write 30/29 MB/s
INFO: status: 4% (4299948032/107374182400), sparse 0% (420032512), duration 140, read/write 30/29 MB/s
INFO: status: 5% (5371854848/107374182400), sparse 0% (439095296), duration 175, read/write 30/30 MB/s
INFO: status: 6% (6447169536/107374182400), sparse 0% (441339904), duration 210, read/write 30/30 MB/s
INFO: status: 7% (7521828864/107374182400), sparse 0% (574980096), duration 246, read/write 29/26 MB/s
INFO: status: 8% (8593735680/107374182400), sparse 0% (590368768), duration 281, read/write 30/30 MB/s

Spoiler: bwlimit 120000

INFO: starting new backup job: vzdump 101 --mode stop --compress 0 --remove 0 --storage local --node proxnode3
INFO: Starting Backup of VM 101 (qemu)
INFO: status = stopped
INFO: update VM 101: -lock backup
INFO: backup mode: stop
INFO: bandwidth limit: 120000 KB/s
INFO: ionice priority: 7
INFO: VM Name: ts.tks-sicherheit.com
INFO: include disk 'scsi0' 'local-zfs:vm-101-disk-1' 100G
INFO: creating archive '/var/lib/vz/dump/vzdump-qemu-101-2018_01_30-12_07_21.vma'
INFO: starting kvm to execute backup task
INFO: started backup task '344fee55-7ae8-45dd-9782-d6054de2e98a'
INFO: status: 0% (184811520/107374182400), sparse 0% (123375616), duration 3, read/write 61/20 MB/s
INFO: status: 1% (1111752704/107374182400), sparse 0% (316547072), duration 18, read/write 61/48 MB/s
INFO: status: 2% (2163081216/107374182400), sparse 0% (361750528), duration 35, read/write 61/59 MB/s
INFO: status: 3% (3228762112/107374182400), sparse 0% (392933376), duration 52, read/write 62/60 MB/s
INFO: status: 4% (4355522560/107374182400), sparse 0% (420352000), duration 70, read/write 62/61 MB/s
INFO: status: 5% (5403312128/107374182400), sparse 0% (439103488), duration 87, read/write 61/60 MB/s
INFO: status: 6% (6480461824/107374182400), sparse 0% (450646016), duration 104, read/write 63/62 MB/s

Spoiler: bwlimit 240000

INFO: starting new backup job: vzdump 101 --remove 0 --compress 0 --storage backup --node proxnode3 --mode stop
INFO: Starting Backup of VM 101 (qemu)
INFO: status = stopped
INFO: update VM 101: -lock backup
INFO: backup mode: stop
INFO: bandwidth limit: 240000 KB/s
INFO: ionice priority: 7
INFO: VM Name: ts.tks-sicherheit.com
INFO: include disk 'scsi0' 'local-zfs:vm-101-disk-1' 100G
INFO: creating archive '/mnt/pve/backup/dump/vzdump-qemu-101-2018_01_30-12_09_52.vma'
INFO: starting kvm to execute backup task
INFO: started backup task 'fb253f51-ca86-4878-a59e-76fde4fd5c11'
INFO: status: 0% (717881344/107374182400), sparse 0% (283394048), duration 3, read/write 239/144 MB/s
INFO: status: 1% (1391394816/107374182400), sparse 0% (335126528), duration 6, read/write 224/207 MB/s
INFO: status: 2% (2286944256/107374182400), sparse 0% (374325248), duration 10, read/write 223/214 MB/s
INFO: status: 3% (3269984256/107374182400), sparse 0% (392933376), duration 14, read/write 245/241 MB/s
INFO: status: 4% (4492820480/107374182400), sparse 0% (420687872), duration 19, read/write 244/239 MB/s
INFO: status: 5% (5463670784/107374182400), sparse 0% (439803904), duration 23, read/write 242/237 MB/s

 

[wolfgang]

Ja ist ein Bug bitte einen Bugzilla Eintrag machen, dann kümmern wir uns darum.

 

[HBO]

Erledigt: https://bugzilla.proxmox.com/show_bug.cgi?id=1642
Das Bug Ticket zwecks qmrestore behalte ich dann mal im Auge.

 

[wolfgang]

Danke @HBO