[SOLVED] Migration sehr langsam - IO-Verzögerung hoch

anderl1969

Member
Jul 10, 2022
70
10
8
Ich hab gestern einen zweiten Proxmox-Node in Betrieb genommen und beide Nodes zu einem Cluster verbunden. Die Hardware ist zweimal identisch;
  • HP Microserver Gen8
  • Xeon E3 1265L v2 (4 Kerne / 8 Threads)
  • 16 GB RAM
  • 120 GB Boot SSD
  • 1 TB SSD für Local Storage (VM-Disks und CT-Volumes)
Das Local Storage ist mit ext2 ext4 und LVM-Thin konfiguriert. Auf ZFS habe ich bewußt verzichtet, da es speicherintensiv sein soll und der Gen8 maximal 16GB RAM kann.

Die Migration von einzelnen VMs und LXCs ist allerdings sehr langsam. Als Beispiel mal das Log eines Containers mit 32GB Volume:

Code:
2023-03-04 10:20:13 shutdown CT 800
2023-03-04 10:20:16 starting migration of CT 800 to node 'pve2' (192.168.1.3)
2023-03-04 10:20:17 found local volume 'local-lvm:vm-800-disk-1' (in current VM config)
2023-03-04 10:20:19   Logical volume "vm-800-disk-1" created.
2023-03-04 10:43:13 524288+0 records in
2023-03-04 10:43:13 524288+0 records out
2023-03-04 10:43:13 34359738368 bytes (34 GB, 32 GiB) copied, 1374.58 s, 25.0 MB/s
2023-03-04 10:45:51 219138+1173195 records in
2023-03-04 10:45:51 219138+1173195 records out
2023-03-04 10:45:51 34359738368 bytes (34 GB, 32 GiB) copied, 1532.18 s, 22.4 MB/s
2023-03-04 10:45:51 successfully imported 'local-lvm:vm-800-disk-1'
2023-03-04 10:45:51 volume 'local-lvm:vm-800-disk-1' is 'local-lvm:vm-800-disk-1' on the target
2023-03-04 10:45:51 # /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve2' root@192.168.1.3 pvesr set-state 800 \''{}'\'
  Logical volume "vm-800-disk-1" successfully removed
2023-03-04 10:45:52 start final cleanup
2023-03-04 10:45:53 start container on target node
2023-03-04 10:45:53 # /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve2' root@192.168.1.3 pct start 800
2023-03-04 10:45:56 migration finished successfully (duration 00:25:43)
TASK OK

Sind 25 min für 32GB normal? Mir fehlt leider der Vergleich.
Die Netzwerkverbindung zwischen den beiden Nodes ist 1GBit und meine iperf Messungen bestätigen das auch. Was auffällt: die IO-Verzögerung steigt während der Migration auf dem Ziel-Node auf 30%-40%
 
Last edited:
Ich hab gestern einen zweiten Proxmox-Node in Betrieb genommen und beide Nodes zu einem Cluster verbunden. Die Hardware ist zweimal identisch;
  • HP Microserver Gen8
  • Xeon E3 1265L v2 (4 Kerne / 8 Threads)
  • 16 GB RAM
  • 120 GB Boot SSD
  • 1 TB SSD für Local Storage (VM-Disks und CT-Volumes)
Das Local Storage ist mit ext2 und LVM-Thin konfiguriert. Auf ZFS habe ich bewußt verzichtet, da es speicherintensiv sein soll und der Gen8 maximal 16GB RAM kann.

Die Migration von einzelnen VMs und LXCs ist allerdings sehr langsam. Als Beispiel mal das Log eines Containers mit 32GB Volume:

Code:
2023-03-04 10:20:13 shutdown CT 800
2023-03-04 10:20:16 starting migration of CT 800 to node 'pve2' (192.168.1.3)
2023-03-04 10:20:17 found local volume 'local-lvm:vm-800-disk-1' (in current VM config)
2023-03-04 10:20:19   Logical volume "vm-800-disk-1" created.
2023-03-04 10:43:13 524288+0 records in
2023-03-04 10:43:13 524288+0 records out
2023-03-04 10:43:13 34359738368 bytes (34 GB, 32 GiB) copied, 1374.58 s, 25.0 MB/s
2023-03-04 10:45:51 219138+1173195 records in
2023-03-04 10:45:51 219138+1173195 records out
2023-03-04 10:45:51 34359738368 bytes (34 GB, 32 GiB) copied, 1532.18 s, 22.4 MB/s
2023-03-04 10:45:51 successfully imported 'local-lvm:vm-800-disk-1'
2023-03-04 10:45:51 volume 'local-lvm:vm-800-disk-1' is 'local-lvm:vm-800-disk-1' on the target
2023-03-04 10:45:51 # /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve2' root@192.168.1.3 pvesr set-state 800 \''{}'\'
  Logical volume "vm-800-disk-1" successfully removed
2023-03-04 10:45:52 start final cleanup
2023-03-04 10:45:53 start container on target node
2023-03-04 10:45:53 # /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve2' root@192.168.1.3 pct start 800
2023-03-04 10:45:56 migration finished successfully (duration 00:25:43)
TASK OK

Sind 25 min für 32GB normal? Mir fehlt leider der Vergleich.
Die Netzwerkverbindung zwischen den beiden Nodes ist 1GBit und meine iperf Messungen bestätigen das auch. Was auffällt: die IO-Verzögerung steigt während der Migration auf dem Ziel-Node auf 30%-40%
Was erwartest du von einem Prozessor aus Q2'12?

Der ist 11 Jahre alt....
Wenn dann noch eine SSD ohne PLP im Einsatz ist, bringen die Waits erst die SSD dann die CPU einfach ans Limit....
 
Last edited:
Ja und?
Der Prozessor hat keine Probleme 2x Windows Server VMs + 1 Debian 11 VM + 5 LXCs zu "hosten". Im Gegenteil: die CPU langweilt sich dabei, das RAM wird eher knapp.

Ich bin jetzt kein Proxmox-Experte, aber was soll bei einer Container-Migration so CPU-belastend sein?

Ich habe jetzt probeweise mal in die andere Richtung migiert, also von Node2 zurück zu Node1:

Code:
2023-03-04 11:43:06 shutdown CT 800
2023-03-04 11:43:29 starting migration of CT 800 to node 'pve1' (192.168.1.2)
2023-03-04 11:43:29 found local volume 'local-lvm:vm-800-disk-1' (in current VM config)
2023-03-04 11:43:31   Logical volume "vm-800-disk-1" created.
2023-03-04 11:48:25 524288+0 records in
2023-03-04 11:48:25 524288+0 records out
2023-03-04 11:48:25 34359738368 bytes (34 GB, 32 GiB) copied, 294.538 s, 117 MB/s
2023-03-04 11:48:28 163+2074913 records in
2023-03-04 11:48:28 163+2074913 records out
2023-03-04 11:48:28 34359738368 bytes (34 GB, 32 GiB) copied, 297.305 s, 116 MB/s
2023-03-04 11:48:28 successfully imported 'local-lvm:vm-800-disk-1'
2023-03-04 11:48:28 volume 'local-lvm:vm-800-disk-1' is 'local-lvm:vm-800-disk-1' on the target
2023-03-04 11:48:28 # /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve1' root@192.168.1.2 pvesr set-state 800 \''{}'\'
  Logical volume "vm-800-disk-1" successfully removed
2023-03-04 11:48:29 start final cleanup
2023-03-04 11:48:30 start container on target node
2023-03-04 11:48:30 # /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve1' root@192.168.1.2 pct start 800
2023-03-04 11:48:33 migration finished successfully (duration 00:05:27)
TASK OK

Das entspricht eher meinen Erwartungen! Hier ist klar das 1 GBit LAN am Limit und der Vorgang dauert nur 5min statt 25min!
Die CPU ist in beiden Nodes übrigens gleich alt (SCNR).

Die IO-Verzögerung bewegte sich bei diesem Durchgang auf dem Target (Node1) übrigens bei 4%-6%.
Die SSDs, die für das LVM-Thin auf beiden Nodes verwendet werden, sind ebenfalls baugleich: Samsung SSD 870 EVO 1TB SATA (MZ-77E1T0B)

Das Problem tritt also nur in 1 Richtung auf. Hat jemand eine Idee, wo ich suchen muss?
 
Hättest du ruhig sagen können, das es nur eine Richtung betrifft.
Vielleicht ist die Ziel-SSD in die eine Richtung beim Schreiben madig oder müsste mal nen TRIM haben?

Wie viel RAM ist denn beim Zielnode noch verfügbar, ist der leer?

* Eine CPU kann übrigends bei 2% idlen und trotzdem am Ende sein. Context-Switching dürfte bei der Anzahl an VMs und LXCs bei 4 Cores schon eine Rolle spielen. Im Windows-Gast kann man sich dazu auch die %DPC Time per Leistungsmonitor holen. Da ist ab 10% auch nicht mehr wirklich performant.
 
  • dass es nur in 1 Richtung Probleme gibt, hatte ich zunächst nicht bemerkt. Ich migriere ja eigentlich vom alten Node auf den neuen, um den alten ein wenig zu entlasten.
  • Der problematische Zielnode ist der neue Node - der eigentlich jungfreulich ist.
    • RAM: von den 16 GB sind >10 GB frei
    • die SSD ist nagelneu
  • wie kommst du auf ext2? es ist ext4.
  • die Migrationsverbindung war auf secure. Aber die wirkt ja nicht nur in 1 Richtung, oder? Hab trotzdem in die /etc/pve/datacenter.cfg jetzt migration: type=insecure eingetragen. Leider ohne Effekt, Von Node 1 zu Node 2 immer noch grottenlangsam mit hoher IO-Verzögerung auf Node2
 
ups, da hatte ich mich verschrieben. Das sollte ext4 heißen.
Ja, die SSDs sind gleich. Werde mal zum Testen noch eine 2TB HDD einbauen, die ich grad zur Hand habe...
 
Irgendwas muss ich beim Einrichten der Storage-SSD verhühnert haben. Mit den temporär eingebauten Festplatten gab's keine Probleme. Die Migration auf Node2 ging nun genauso "schnell" (was ein 1GBit LAN halt max. zulässt) wie in die andere Richtung!

Also die SSD auf Node 2 wieder leer geräumt und neu eingerichtet. Diesmal gleich als ZFS-Pool (mein RAM Problem mit max 16GB ist ja jetzt entschärft, da sich meine VMs und Container auf 2 Nodes verteilen können). Dasselbe auf Node 1. Läuft wunderbar :)

Mit ZFS und Replikation macht das ganze noch viel mehr Freude.

Jetzt habe ich mir noch ein Qdevice ins LAN geschraubt und teste mal HA.
 
  • Like
Reactions: Falk R.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!