VM sehr langsam, zu schwache Hardware für Proxmox?

[Detlef Paschke]

Hallo,

meine ersten Gehversuche mit Proxmox laufen nun schon ein paar Tage aber nun bin ich wieder an einem Punkt der Verzweiflung angekommen.

Kann es sein, dass die Hardware welche ich nutzen möchte für Proxmox doch zu bescheiden ist?

Das System sieht so aus: Supermicro X7DB8 mit zwei Xeon E5345 und 32GB Ram, Proxmox und VMs aus FUJITSU MAW3300NC in ext4.

Das Problem ist nun, dass die VMs sehr langsam arbeiten und wie ich beobachtet habe wohl tatsächlich in Bezug auf Rechenleistung.

Nur als Vergleich, ich habe hier ein Serversystem Eisfair bzw. Eisfair64 auf einer HW-Maschine und einmal als VM unter Proxmox. Wenn ich dort nun ein Update der Patentdatenbank fahre ist der Unterschied deutlich zu sehen. Bei diesem Update werden kaum Daten geladen, es geht in erster Linie um Rechenleistung.
Mehr Arbeitsspeicher und mehr Kerne haben keine Veränderung gebracht.

HW-Eisfair1 2 x Xeon "Irwindale" 3,8GHz, 16GB DDR2

eisfair # time eisman update
(Re)building package database ...
[100%] completed!
Done!
(Re)building outdated database ...
please wait!
Done!

real 0m53.691s
user 0m8.216s
sys 0m4.280s
eisfair #

VM-Eisfair64 2/2 KVM64 8GB Ram

eisfair64 # time eisman update
(Re)building package database ...
[100%] completed!
Done!
(Re)building outdated database ...
please wait!
Done!

real 4m57.019s
user 3m34.112s
sys 2m40.764s
eisfair64 #

Zum testen habe ich gerade einmal ein Kubuntu-VM erstellt. Das erste Update läuft gerade seit mehr als zwei Stunden.
Der Download war aber schnell erledigt, habe ich auch getestet und ist unauffällig.

Ich gib gern weitere Informationen und bin für jeden Tipp dankbar.

Viele Grüße
Detlef Paschke

 

[udo]

Hallo,

meine ersten Gehversuche mit Proxmox laufen nun schon ein paar Tage aber nun bin ich wieder an einem Punkt der Verzweiflung angekommen.

Kann es sein, dass die Hardware welche ich nutzen möchte für Proxmox doch zu bescheiden ist?

Das System sieht so aus: Supermicro X7DB8 mit zwei Xeon E5345 und 32GB Ram, Proxmox und VMs aus FUJITSU MAW3300NC in ext4.

Das Problem ist nun, dass die VMs sehr langsam arbeiten und wie ich beobachtet habe wohl tatsächlich in Bezug auf Rechenleistung.

Nur als Vergleich, ich habe hier ein Serversystem Eisfair bzw. Eisfair64 auf einer HW-Maschine und einmal als VM unter Proxmox. Wenn ich dort nun ein Update der Patentdatenbank fahre ist der Unterschied deutlich zu sehen. Bei diesem Update werden kaum Daten geladen, es geht in erster Linie um Rechenleistung.
Mehr Arbeitsspeicher und mehr Kerne haben keine Veränderung gebracht.

HW-Eisfair1 2 x Xeon "Irwindale" 3,8GHz, 16GB DDR2

eisfair # time eisman update
(Re)building package database ...
[100%] completed!
Done!
(Re)building outdated database ...
please wait!
Done!

real 0m53.691s
user 0m8.216s
sys 0m4.280s
eisfair #

VM-Eisfair64 2/2 KVM64 8GB Ram

eisfair64 # time eisman update
(Re)building package database ...
[100%] completed!
Done!
(Re)building outdated database ...
please wait!
Done!

real 4m57.019s
user 3m34.112s
sys 2m40.764s
eisfair64 #

Zum testen habe ich gerade einmal ein Kubuntu-VM erstellt. Das erste Update läuft gerade seit mehr als zwei Stunden.
Der Download war aber schnell erledigt, habe ich auch getestet und ist unauffällig.

Ich gib gern weitere Informationen und bin für jeden Tipp dankbar.

Viele Grüße
Detlef Paschke

Hi Detlef,
wie sieht es denn aus, wenn Du den CPU-Typ auf Host stellst (VM dann stoppen und wieder starten)?
Ich kenne Eisfair nicht, aber ein Versuch wäre es wert.
Und wie sind die Bios-Einstellungen? Gelegentlich gibt's Performance-Probleme, wenn im Bios nicht als Modus Performance (je nach Hersteller unterschiedlich) ausgewählt ist.
Nebenbei gesagt, ist mit 12 Jahre alter Hardware auch nicht allzu viel zu erwarten... aber Dein Vergleichssystem ist ja ähnlich aktuell.

Udo

 

[Detlef Paschke]

Hallo Udo,
Bei CPU-Typ habe ich bereits host Probiert und hatte keinen Erfolg.
Mit einem einfachen Rechentest:
time echo "scale=5000; 4*a(1)" | bc -l
hatte ich mit host schlechtere Werte als mit kvm64.

Bios Einstellungen habe ich noch mal durchgesehen und scheinen mir alle so in Ordnung zu sein. Der Proxmox an sich auf der Hardware arbeitet auch Tadellos und ohne auffällige Verzögerungen . Nur zwischen Proxmox und VM scheint ein Stein auf der Bremse zu liegen.

Ja, nicht aktuelle Hardware sicher, aber für einen kleinen Heimserver und ein wenig Bastelei hat es immer gereicht. Und selbst wenn ich könnte würde ich mir dafür keinen i7 hinstellen. Nur dass jetzt bei der VM so derart viel Leistung irgend wo verschwinden soll ist mir schleierhaft. Und, der Eisfair ist nun beim besten willen kein Hardware-hungriges System, ganz im Gegenteil. Aber wie ich schon schrob, auch bei Kubuntu war die Leistung weg, Ubuntu wollte erst mal gar nicht starten. Muss ich weiter schauen.

Testen könnte ich noch, ob evtl. die Meltdown und Spectre Patches, so wie ich immer wieder lese und höre, auch bei Proxmox großen Leistungsverlust verursachen. Müsste ich mal suchen, wie man die test weise deaktivieren kann und wenn es an denen ist, wüsste ich wenigstens woran es liegt .

Viele Grüße
Detlef Paschke

 

[udo]

Hi,
wie sieht denn Deine vm-config aus? (cat /etc/pve/qemu/VMID.conf )


Udo

 

[Detlef Paschke]

Hallo Udo,
die durchgereichten Platten scsi1 bis scsi5 bei der VM 100 haben keinen Einfluss auf den Leistungsverlust. Ist auch ohne diese Platten so. Getestet habe ich auch schon mit LSI 53C8xxx anstelle VirtIO SCSI. Der LSI ist nach meiner Beobachtung auch etwas schneller als der VirtIO. bringt bei der Rechenleistung aber leider nichts.

Viele Grüße
Detlef Paschke

 

[udo]

Hi,
ich hab' mal "time echo "scale=5000; 4*a(1)" | bc -l" auf einem low-power-embedded amd system und einem Xeon E5620 mit Spectre-Patchen getestet.
Scheint für bc nicht wirklich relevant zu sein (ist allerdings jeweils nur ein Test pro Lauf):

Host amd low power:
real    1m45.255s

VM (cpu kvm64):
real    1m51,747s
=106.17%

VM (cpu host):
real    1m50,859s
=105.32%
######################## XEON E5620 ###########################
Host:
real    0m29.231s

VM (kvm64,flags=+pcid;+spec-ctrl):
real    0m31.409s
=107.45%

Virtualisierung kostet etwas CPU, aber es hält sich durchaus in Grenzen.

Tritt das gleiche Verhalten auf, wenn Du nur ein Socket und ein Core verwendest?

Udo

 

[Detlef Paschke]

Hallo Udo,

mit nur einem Core teste ich dann morgen.
Ich habe diesen Test im übrigen schon mal als Vergleich mit meinem HW-Server dem Proxmox selbst und den VMs angestellt und da zeigte sich nicht eine derartige Diskrepanz. Im Gegenteil ist dort wie zu erwarten der E5345 (an dessen stelle jetzt ein X5460 ist) etwas schneller als der Irwindale Xeon.

HW-Eisfair1 2 x Xeon "Irwindale" 3,8GHz
time echo "scale=5000; 4*a(1)" | bc -l
...
real 0m44.005s
user 0m44.004s
sys 0m0.000s

HW-Proxmox 2 x Xeon E5345 2,33Ghz
time echo "scale=5000; 4*a(1)" | bc -l
...
real 0m33,230s
user 0m33,220s
sys 0m0,009s

VM-Eisfair64 2/2 KVM64
time echo "scale=5000; 4*a(1)" | bc -l
...
real 0m33.373s
user 0m33.364s
sys 0m0.012s

VM-Eisfair1 2/2 KVM64
time echo "scale=5000; 4*a(1)" | bc -l
...
real 0m37.129s
user 0m37.120s
sys 0m0.008s

 

[udo]

Hi,
demnach ist doch mit der CPU alles ok, oder?!

Wenn es laggy ist, siehst Du mit atop iowait?

Udo

 

[Detlef Paschke]

Hallo Udo,
im ersten Moment sieht es in der Tat so aus, als ob es nicht in Richtung CPU geht aber was mir ungewöhnlich erscheint, ist der marginale Unterschied der Ergebnisse bei unterschiedlichen CPU-Konfigurationen. Es macht nahezu keinen oder nur einen geringen Unterschied, ob ich nun einen oder acht Kerne für die VM verwende.

VM-Eisfair64 1S/1C KVM64
time echo "scale=5000; 4*a(1)" | bc -l >/dev/null
real 0m31.115s
user 0m24.472s
sys 0m0.000s

VM-Eisfair64 2S/1C KVM64
time echo "scale=5000; 4*a(1)" | bc -l >/dev/null
real 0m27.259s
user 0m27.216s
sys 0m0.004s

VM-Eisfair64 1S/2C KVM64
time echo "scale=5000; 4*a(1)" | bc -l >/dev/null
real 0m26.956s
user 0m26.932s
sys 0m0.004s

VM-Eisfair64 2S/2C KVM64
time echo "scale=5000; 4*a(1)" | bc -l >/dev/null
real 0m27.448s
user 0m27.416s
sys 0m0.012s

VM-Eisfair64 2S/4C KVM64
time echo "scale=5000; 4*a(1)" | bc -l >/dev/null
real 0m27.264s
user 0m27.240s
sys 0m0.012s

Wenn es laggy ist, siehst Du mit atop iowait?

Hier bin ich mit meinen beschiedenen Kenntnissen Raus.
Und ich habe mal geschaut, atop haben wir bei Eisfair offensichtlich nicht, ich finde es zumindest nicht, müsste ich erst von einer anderen Quelle holen. Htop könnte ich noch anbieten. Und noch eine dumme Frage, was ist "laggy"?

Viele Grüße
Detlef Paschke

 

[udo]

Hallo Udo,
im ersten Moment sieht es in der Tat so aus, als ob es nicht in Richtung CPU geht aber was mir ungewöhnlich erscheint, ist der marginale Unterschied der Ergebnisse bei unterschiedlichen CPU-Konfigurationen. Es macht nahezu keinen oder nur einen geringen Unterschied, ob ich nun einen oder acht Kerne für die VM verwende.

Hi Detlef,
das ist kein wunder, bc ist single threated, dass heisst, weiter Cores langweilen sich in der Zeit nur und bringen keine Performance-Steigerung.

Hier bin ich mit meinen beschiedenen Kenntnissen Raus.
Und ich habe mal geschaut, atop haben wir bei Eisfair offensichtlich nicht, ich finde es zumindest nicht, müsste ich erst von einer anderen Quelle holen. Htop könnte ich noch anbieten. Und noch eine dumme Frage, was ist "laggy"?

Viele Grüße
Detlef Paschke

mit "laggy" meine ich, wenn es sich lahm anfühlt. Du brauchst nicht atop verwenden (obwohl es sehr hilfreich sein kann). Top zeigt auch wait an.

Udo

 

[Detlef Paschke]

Hallo Udo,

ich hab mich mal zwischenzeitlich etwas belesen und glaube gefunden zu haben welche Werte Dich interessieren.

Bei Top wäre es dann wohl wa und der liegt bei 0.0 bis 2.7 in der Zeit in der das Update der Paketdatenbank läuft.
Bei iostate geht es wohl um %iowait und da hatte ich Werte zwischen 0.00 und max. 4.55.
Kann also auch nicht die Ursache sein, wenn ich bedenke, dass ich im Netz von Werten um 40 bis 70 Prozent gelesen habe bei Leuten die damit Probleme hatten.

Bin völlig Ratlos, Download-Geschwindigkeit getestet und alles da was der Anschluss hergibt. Festplatten Werte mit anderen Usern verglichen und nicht wirklich auffällige Abweichungen gefunden.
hdparm -Tt /dev/sda
Timing cached reads: 12676 MB in 1.92 seconds = 6610.30 MB/sec
Timing buffered disk reads: 948 MB in 3.01 seconds = 315.25 MB/sec

dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
1024+0 records in
1024+0 records out
402653184 bytes (403 MB, 384 MiB) copied, 0.569663 s, 707 MB/s

Und auch der einfache Rechentest mit den Pi Nachkommastellen ausrechnen zeigt, "Es sollte gehen!".
Ich fahre jetzt mit 8 Kernen und merke nahezu keinen Unterschied. Lt. lscpu sind sie aber da.

Eisfair64 # lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 2
Vendor ID: GenuineIntel
CPU family: 15
Model: 6
Model name: Common KVM processor
Stepping: 1
CPU MHz: 3166.666
BogoMIPS: 6333.33
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
L3 cache: 16384K
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology eagerfpu pni cx16 x2apic hypervisor lahf_lm kaiser
Eisfair64 #

Viele Grüße
Detlef Paschke

 

[Detlef Paschke]

Was mir gerade aufgefallen ist, ich habe atop einmal auf Proxmox selbst ausgeführt und dort fiel mir die CPU Last von KVM auf.
Wenn die VM nur so vor sich rum rödelt und nicht macht sind die Werte um die 30% bis 50 % kurzzeitig mal bis 150%. Mache ich in der VM ein Update der Paketdatenbank geht auf Proxmox der Wert für KVM stabil über 300% und teilweise bis zu 400%.

Viele Grüße
Detlef Paschke

 

[udo]

Hallo Udo,

ich hab mich mal zwischenzeitlich etwas belesen und glaube gefunden zu haben welche Werte Dich interessieren.

Bei Top wäre es dann wohl wa und der liegt bei 0.0 bis 2.7 in der Zeit in der das Update der Paketdatenbank läuft.
Bei iostate geht es wohl um %iowait und da hatte ich Werte zwischen 0.00 und max. 4.55.
Kann also auch nicht die Ursache sein, wenn ich bedenke, dass ich im Netz von Werten um 40 bis 70 Prozent gelesen habe bei Leuten die damit Probleme hatten.

Bin völlig Ratlos, Download-Geschwindigkeit getestet und alles da was der Anschluss hergibt. Festplatten Werte mit anderen Usern verglichen und nicht wirklich auffällige Abweichungen gefunden.
hdparm -Tt /dev/sda
Timing cached reads: 12676 MB in 1.92 seconds = 6610.30 MB/sec
Timing buffered disk reads: 948 MB in 3.01 seconds = 315.25 MB/sec

dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
1024+0 records in
1024+0 records out
402653184 bytes (403 MB, 384 MiB) copied, 0.569663 s, 707 MB/s

Hi,
was für ein Storage-system hast du denn auf dem pve-host? (lvm auf hardware raid? Oder zfs?)
Bei zfs wäre der dd-Test z.B. nichtssagend, weil die Nullen komprimiert werden.

Und auch der einfache Rechentest mit den Pi Nachkommastellen ausrechnen zeigt, "Es sollte gehen!".
Ich fahre jetzt mit 8 Kernen und merke nahezu keinen Unterschied. Lt. lscpu sind sie aber da.

wenn ich es richtig sehe, hat Dein gesamtes System 8 cores. Dann kannst Du auch 8 Cores an einer VM vergeben, nur nicht mehr.
Wenn mehr cores vergeben sind, als das System hat, wird's richtig langsam!

Und bei so'n alten system kann auch das Bios buggy sein, und mit dem Numa was nicht hinhauen... deshalb die bereits gestellt Frage: Wie arbeitet eine VM mit einem Core?

Udo

 

[Detlef Paschke]

Hallo,

was für ein Storage-system hast du denn auf dem pve-host? (lvm auf hardware raid? Oder zfs?)
Bei zfs wäre der dd-Test z.B. nichtssagend, weil die Nullen komprimiert werden.

ganz anders, klassische ext4 Partitionierung mit boot swap und root Partition ohne lvm zfs oder sonst was, über den Debian Weg installiert.

Ja, und mit nur einem Core habe ich heute mal getestet, bringt nahezu keine anderen Werte. Als ob mehr Kerne gar nicht genutzt würden.

Viele Grüße
Detlef Paschke

 

[Detlef Paschke]

Hallo,

ganz anders, klassische ext4 Partitionierung mit boot swap und root Partition ohne lvm zfs oder sonst was, über den Debian Weg installiert.

da es hin und wieder schon Fragen und Bedenken nach dem Motto "...warum nimmst Du kein LVM... evtl. liegt es daran..." gegeben hat, habe ich mal eine "saubere" Proxmox Installation von der proxmox-ve_5.3-2.iso mit ext4 und LVM auf eine andere Platte gemacht. Auf diese "saubere" Installation dann eine VM aufgesetzt und verglichen.

Das Ergebnis ist nahezu identisch. Zwischen einer und zwei CPU merkt man eine leichte Verbesserung, alles was an CPUs darüber hinaus vergeben wird macht keinen Sinn mehr. Insgesamt bleiben die VMs aber deutlich zu träge.

Viele Grüße
Detlef Paschke

 

[Detlef Paschke]

Hallo,

Zwischen einer und zwei CPU merkt man eine leichte Verbesserung, alles was an CPUs darüber hinaus vergeben wird macht keinen Sinn mehr.

ein wenig revidieren muss ich wohl.
Ich habe noch mal einen Vergleich angestellt - wieder mit dem Update der Paketdatenbank - und konnte feststellen, dass zumindest Parallelisierung zu funktionieren schein.
Arbeitet die VM mit zwei CPUs ist die Auslastung durchschnittlich bei ca. 80% in Spitzen über 100%. Selbst wenn die VM nichts mehr macht sehe ich immer wieder Spitzen bis 80%. Mit vier CPUs liegt der Durchschnitt beim Update bei ca. 45% in Spitzen bis 80%.

Viele Grüße
Detlef Paschke

 

[Knuuut]

Ich lehne mich mal weit aus dem Fenster: Kann es sein, dass die Virtualisierungsfunktion(VT-X) im BIOS vom Host deaktiviert ist?
Das kannst du schnell überprüfen mit
cat /proc/cpuinfo
sollte unter flags vmx aufführen. Wenn nicht dann im BIOS nachsehen.

Cheers Knuuut

 

[Detlef Paschke]

Hallo,
doch doch, VT-X ist aktiviert.
Ich habe aber in Erfahrung gebracht, dass alle Supermicro X7 Boards Numa noch nicht unterstützen. Evtl. liegt es daran.
Vor ein paar Tagen habe ich mal einige alte Proxmox-Versionen, angefangen bei Proxmox 1.6irgendwas getestet um zu sehen, ob evtl. bei einer älteren Version der Leistungsverlust nicht so hoch war. Leider negativ.
Jetzt bin ich dabei, andere VM-Lösungen zu suchen und zu testen um den Leistungsverlust evtl. etwas zu verringern. Tja, oder evtl. irgend eine Bootoption für Proxmox die irgend etwas aus- oder Einschaltet. Aber erst mal geben und davon wissen um es Testen zu können. Wenn ich den benötigten Server Eisfair direkt auf die Hardware installiere Braucht das Update der Paketdatenbank ca. 30sek. als VM unter Proxmox ca. 5min, das ist schon reichlich. Man sieht es aber auch schon beim Booten wenn die Pinguine für die Anzahl der Kerne gezeigt werden. Als HM sind sie sofort da und als VM werden sie deutlich Zeilenweise aufgebaut. Das wäre natürlich kein Thema, aber der gesamte Leistungsverlust schon.

Viele Grüße
Detlef Paschke

 

[Knuuut]

Ich habe aber in Erfahrung gebracht, dass alle Supermicro X7 Boards Numa noch nicht unterstützen. Evtl. liegt es daran.

Dann baue doch mal zum Spaß 1 CPU aus...

 

[Detlef Paschke]

Hallo,
kann ich mal testen, hat NUMA nur etwas mit mehreren CPUs aber nicht mit mehreren Kernen zu tun?
Viele Grüße
Detlef Paschke