Proxmox 8.2.2 - Windows Server träge

[Tived]

Hallo Leute,

ich bin vor einigen Tagen von ESXI auf Proxmox umgestiegen. Soweit läuft alles und ich bin ganz zufrieden.

Nun habe ich diverse Linux VMs aber auch zwei Windows Server am laufen.

Leider sind die beiden Windows Server relativ träge. Die CPU Auslastung liegt bei ungefähr 20% und die RAM Auslastung bei 50%.
Beim Arbeiten via RDP auf dem Server dauert alles deutlich länger als früher.

Auf dem Server liegen diverse Netzwerkfreigaben. Unter anderem haben wir eine Software die auf einer Netzwerkfreigabe läuft. Hier merkt man auch deutlich das alles etwas langsamer läuft.

Ich habe diverse Foren durchforstet und einige Anhaltspunkte getestet. Leider bis dato kein spürbarer Unterschied.
Hat noch jemand Tipps wie ich solch ein Problem angehen kann? Wäre sehr dankbar!

Anbei ein paar Screenshots:





LG Leon

 

[UdoB]

Nur ein kleines Schnipsel, sicher nicht dein eigentliches Problem: dein Windows nutzt 16 Kerne und du hast zwei solcher VMs plus weitere Linuxe...

Der Host hat 32 Kerne. Diese VM kann NUR dann laufen, wenn in derselben Mikrosekunde 16 Kerne FREI sind - das gilt auch dann, wenn wie im Screenshot nur ein einzelner Kern benötigt wird. Sofern noch andere VMs (oder allgmeine: Prozesse, auch des Hosts) laufen, kann also immer nur eine dieser zwei Windows VMs laufen, niemals beide gleichzeitig.

Ja, man kann CPUs massiv over-committen, aber am Ende hat man zu jedem Mikro-Zeitpunkt/-Intervall nur die real vorhandenen Ressourcen!

Also: gib dieser Art VM "nur" acht Kerne und das Gesamtsystem wird runder laufen. (Sofern die VMs die 16 Kerne nicht wirklich benötigen...)

Just my 2 €¢...

 

[Falk R.]

Eigentlich ist das ganze noch schlimmer als Udo beschreibt. Das ist eine 16 Core CPU mit 32 Threads. Ich würde die Core Anzahl einmal drastisch reduzieren. Von der Auslastung her sollte die VM ja mit 2-3 Cores auskommen. Die VM sollte dadurch deutlich schneller werden.

Nutzt ihr zufällig ZFS? Das könnte den Storagezugriff auch träger machen, vor allem bei extremer Überbuchung der CPU.

Oft bringt es auch noch eine Menge, wenn man im Bios High Performance konfiguriert und bei BIOS ohne Profilsteuerung, die CPU C-States deaktivieren.

 

[Tived]

Nur ein kleines Schnipsel, sicher nicht dein eigentliches Problem: dein Windows nutzt 16 Kerne und du hast zwei solcher VMs plus weitere Linuxe...

Der Host hat 32 Kerne. Diese VM kann NUR dann laufen, wenn in derselben Mikrosekunde 16 Kerne FREI sind - das gilt auch dann, wenn wie im Screenshot nur ein einzelner Kern benötigt wird. Sofern noch andere VMs (oder allgmeine: Prozesse, auch des Hosts) laufen, kann also immer nur eine dieser zwei Windows VMs laufen, niemals beide gleichzeitig.

Ja, man kann CPUs massiv over-committen, aber am Ende hat man zu jedem Mikro-Zeitpunkt/-Intervall nur die real vorhandenen Ressourcen!

Also: gib dieser Art VM "nur" acht Kerne und das Gesamtsystem wird runder laufen. (Sofern die VMs die 16 Kerne nicht wirklich benötigen...)

Just my 2 €¢...

Danke für den Hinweis. Ich habe die CPUs bei beiden Windows VMs reduziert. Mal schauen wie sich die Perfomance im Betrieb verhält.

Eigentlich ist das ganze noch schlimmer als Udo beschreibt. Das ist eine 16 Core CPU mit 32 Threads. Ich würde die Core Anzahl einmal drastisch reduzieren. Von der Auslastung her sollte die VM ja mit 2-3 Cores auskommen. Die VM sollte dadurch deutlich schneller werden.

Nutzt ihr zufällig ZFS? Das könnte den Storagezugriff auch träger machen, vor allem bei extremer Überbuchung der CPU.

Oft bringt es auch noch eine Menge, wenn man im Bios High Performance konfiguriert und bei BIOS ohne Profilsteuerung, die CPU C-States deaktivieren.

Ich nutze kein ZFS. Ich habe ein Hardware Raid.

Hast du bezüglich der beiden BIOS Hinweise mehr Infos? Gibts da ne Doku wo das erklärt wird?

Schon mal Danke für eure Hilfe!

 

[Falk R.]

Wenn du z.B. einen HPE oder DELL Server hast, da gibt es vorgefertigte Profile. Da empfiehlt sich immer Virtualisierung High Performance.
Bei Standard BIOS einfach bei den CPU oder Power Einstellungen die C-States deaktivieren.
Du kannst auch jeden beliebigen vSphere oder HYperV Performance Guide nehmen. Alle Hersteller empfehlen da das gleiche.

 

[ivenae]

Oh je, jetzt kommt hier die Gegenmeinung:

Ich hatte nie Probleme mit dem Überbuchen der CPU, insbesondere dann nicht, wenn sie – wie in den meisten Szenarien – ohnehin brach liegt.
(Tatsächlich hätte ich der Maschine aber auch nur 8 Kerne gegeben, wenn sie keine CPU intensive Arbeit macht.)
Nichts kann man so schön Überbuchen bei einer VM wie die CPU, sofern man nicht unbedingt rechenintensive Jobs hat.
Auch den Tipp, die C-States zu deaktivieren kann ich nicht ganz nachvollziehen. Strom kostet auch den Mittelständler Geld, und wir reden hier von einem zusätzlichen Mehrverbrauch von durchaus Faktor 2 - 3 Gesamtleistung des Servers. Und auch hier: Bisher keine Probleme gehabt. Im Gegenteil, ich habe sogar mal den kernel-governor von 'performance' auf 'powersave' gestellt und merke keinen Leistungsunterschied der Systeme (allerdings ist auch die Stromersparnis ausgeblieben).

Für mich sieht das so aus, als ob du Memory Ballooning nicht deaktiviert hast. Dazu ist zusätzlich KSM aktiv. Aus meiner Sicht, korrigiert mich hier gerne, machen beide etwas ähnliches. Sie geben freien Speicher der VMs an das Host-System zurück. Die dahinderstehende Technik ist halt grundsätzlich eine völlig andere, und genau das macht es aus meiner Sicht umso schlimmer, auch noch beides zu aktivieren.

Wenn das keine Maschine ist, die spontan viel RAM braucht, passe den RAM besser an deine Gegebenheiten an und deaktiviere unter wirklich allen Umständen mindestens eines von beiden, ich würde dazu tendieren ballooning zu deaktivieren (via Hardware -> Memory -> Ballooning device), besser auch KSM (siehe: https://pve.proxmox.com/wiki/Kernel_Samepage_Merging_(KSM)) . Das waren bei mir durchaus schon einmal Performance-Fresser.
Eine VM, der du zu wenig RAM gegeben hast fängt an zu Swappen, sie crasht nicht mit einem OOM. Swap ist unschön, mehr aber auch nicht. Es kann dann immer noch granular der eine oder andere Gigabyte zwischen den VMs verschoben werden.

Und: Zusätzliche 64 GB RAM ist über die Laufzeit sicher billiger als der C-State Strom. ;-)

Wenn die Maschine nicht genügend RAM hat und du keinen RAM spontan nachbauen kannst, gerade dann ist es blöd sich auf ballooning und ksm zu verlassen, denn wenn der Speicher mal fehlt, den diese Services dem Host zurückgeben, crash der OOM eine deiner VMs. Das ist unschön.

Ich minimiere lieber den ZFS ARC Speicher [für dich nicht relevant] (was aktuelle Proxmox Installationen ohnehin schon bei Installation machen). Ich persönlich nutze hier zwischen 2 GB (bei 8 GB Host RAM für kleine Systeme) und 7 GB (für Systeme mit 64 GB RAM). Im letzteren Fall könntest du noch ca. 56 GB auf die VMs verteilen ( 1 GB Proxmox + 7 GB ARC + 56 GB VMs = 64 GB Gesamt)
Egal wie ich es drehe und wende: ballooning + KSM bringen mir das Risiko eines OOM, wenn ich hierdurch den Host-RAM überbuche. Ich kann RAM – im Gegensatz zur CPU – so oder so nicht überbuchen und damit fällt der Sinn und Zweck dieser Mittel für mich weg.

Dazu: Proxmox mag keine Hardware-RAID Controller. Besser M.2 SSDs mit ZFS Mirror.

 

[Falk R.]

Oh je, jetzt kommt hier die Gegenmeinung:

Ich hatte nie Probleme mit dem Überbuchen der CPU, insbesondere dann nicht, wenn sie – wie in den meisten Szenarien – ohnehin brach liegt.
(Tatsächlich hätte ich der Maschine aber auch nur 8 Kerne gegeben, wenn sie keine CPU intensive Arbeit macht.)
Nichts kann man so schön Überbuchen bei einer VM wie die CPU, sofern man nicht unbedingt rechenintensive Jobs hat.
Auch den Tipp, die C-States zu deaktivieren kann ich nicht ganz nachvollziehen. Strom kostet auch den Mittelständler Geld, und wir reden hier von einem zusätzlichen Mehrverbrauch von durchaus Faktor 2 - 3 Gesamtleistung des Servers. Und auch hier: Bisher keine Probleme gehabt. Im Gegenteil, ich habe sogar mal den kernel-governor von 'performance' auf 'powersave' gestellt und merke keinen Leistungsunterschied der Systeme (allerdings ist auch die Stromersparnis ausgeblieben).

Siehst du, die Ersparnis ist echt gering. Du musst die Anschaffung stärkerer Hardware gegen die Stromkosten kalkulieren, da bringt es immer mehr, die vorhandene Hardware besser auszulasten.
Du kannst ja auch munter überbuchen, hast du auf einem 32 Core Server 100 VMs mit 2 Cores, wird das immer noch gut performen. Hast du aber 4 x 32 Core VMs, geht die Latenz extrem hoch. Deshalb, lieber weniger Cores pro VM und dann gern mehr VMs, da kann der CPU Scheduler deutlich besser verteilen. Bei Clustern mit mehreren Hundert VMs spürst du solche Änderungen ganz schön.

Für mich sieht das so aus, als ob du Memory Ballooning nicht deaktiviert hast. Dazu ist zusätzlich KSM aktiv. Aus meiner Sicht, korrigiert mich hier gerne, machen beide etwas ähnliches. Sie geben freien Speicher der VMs an das Host-System zurück. Die dahinderstehende Technik ist halt grundsätzlich eine völlig andere, und genau das macht es aus meiner Sicht umso schlimmer, auch noch beides zu aktivieren

Da Denke ich es ist etwas Geschmackssache, wenn man genug RAm hat, ist es eigentlich egal, was du konfigurierst.

Wenn das keine Maschine ist, die spontan viel RAM braucht, passe den RAM besser an deine Gegebenheiten an und deaktiviere unter wirklich allen Umständen mindestens eines von beiden, ich würde dazu tendieren ballooning zu deaktivieren (via Hardware -> Memory -> Ballooning device), besser auch KSM (siehe: https://pve.proxmox.com/wiki/Kernel_Samepage_Merging_(KSM)) . Das waren bei mir durchaus schon einmal Performance-Fresser.
Eine VM, der du zu wenig RAM gegeben hast fängt an zu Swappen, sie crasht nicht mit einem OOM. Swap ist unschön, mehr aber auch nicht. Es kann dann immer noch granular der eine oder andere Gigabyte zwischen den VMs verschoben werden.

Wie gesagt, das passiert nur wenn der RAM zu voll ist.

Und: Zusätzliche 64 GB RAM ist über die Laufzeit sicher billiger als der C-State Strom. ;-)

Was hat der RAM mit den C-States zu tun? Vor allem die paar Watt, kosten im Mittelstand in der Regel auch noch weniger als zuhause.

Wenn die Maschine nicht genügend RAM hat und du keinen RAM spontan nachbauen kannst, gerade dann ist es blöd sich auf ballooning und ksm zu verlassen, denn wenn der Speicher mal fehlt, den diese Services dem Host zurückgeben, crash der OOM eine deiner VMs. Das ist unschön.

Ich minimiere lieber den ZFS ARC Speicher [für dich nicht relevant] (was aktuelle Proxmox Installationen ohnehin schon bei Installation machen). Ich persönlich nutze hier zwischen 2 GB (bei 8 GB Host RAM für kleine Systeme) und 7 GB (für Systeme mit 64 GB RAM). Im letzteren Fall könntest du noch ca. 56 GB auf die VMs verteilen ( 1 GB Proxmox + 7 GB ARC + 56 GB VMs = 64 GB Gesamt)
Egal wie ich es drehe und wende: ballooning + KSM bringen mir das Risiko eines OOM, wenn ich hierdurch den Host-RAM überbuche. Ich kann RAM – im Gegensatz zur CPU – so oder so nicht überbuchen und damit fällt der Sinn und Zweck dieser Mittel für mich weg.

ARC Limitieren ist eine gute Idee, ich mag es auch lieber wenn ich alles unter Kontrolle habe.

Dazu: Proxmox mag keine Hardware-RAID Controller. Besser M.2 SSDs mit ZFS Mirror.

Kann man so nicht sagen. Viele Leute aus der Open Source Community mögen kein Hardware Raid.
Da ich seit über 25 Jahren mit Hardware Raid arbeite, weiß ich wie es funktioniert und dass es gut funktioniert. Alle Probleme mit Hardware Raid die ich bisher gesehen habe, waren immer Menschliche Fehler, entweder falsch konfiguriert oder falsch benutzt. Selbst bei dem einen gestorbenen Raid Controller, den ich in 25 Jahren hatte, ist nix an den Daten kaputt gegangen, es gab nur eine Downtime. Dass kann die auch bei jedem HBA passieren.
Wenn man Hardware Raid richtig konfiguriert, kann man aber aus HDDs und SATA SSDs deutlich mehr Performance raus holen als Nativ.

 

[garfield2008]

Was auch Performance bringt ist das einschalten der Energieprofiles Höchstleistung in der VM.

 

[Falk R.]

Was auch Performance bringt ist das einschalten der Energieprofiles Höchstleistung in der VM.

Aber nur wenn die C-States aktiviert sind. Wenn die im Bios schon deaktiviert sind, ändert das nichts, außer dass z.B. Screensaver deaktiviert werden. Die sollte heutzutage aber eh keiner mehr haben.

 

[garfield2008]

Aber nur wenn die C-States aktiviert sind. Wenn die im Bios schon deaktiviert sind, ändert das nichts, außer dass z.B. Screensaver deaktiviert werden. Die sollte heutzutage aber eh keiner mehr haben.

Hab ich andere Erfahrungen gemacht. Zumindest Clientbetriebssysteme haben da Probleme gemacht, teilweise waren die Maschinen dann nach einem Tag nicht mehr per RDP ansprechbar. Seitdem hab ich bei allen Installationen einen WMI Filter der auf VMs das Powerprofile setzt.
Kann natürlich sein, das das ein Fehler in älteren virtIO Tools war.

 

[Falk R.]

Hab ich andere Erfahrungen gemacht. Zumindest Clientbetriebssysteme haben da Probleme gemacht, teilweise waren die Maschinen dann nach einem Tag nicht mehr per RDP ansprechbar. Seitdem hab ich bei allen Installationen einen WMI Filter der auf VMs das Powerprofile setzt.
Kann natürlich sein, das das ein Fehler in älteren virtIO Tools war.

Ja, Clients gehen in eine Art Ruhemodus, aber soetwas virtualisiert man ja normalerweise nicht.