Terminalserver unter PVE langsam

[cklahn]

Hallo Forum,

ein Kunde hatte einen HPE-Server mit VMware und virtualisiertem DC, Exchange und Terminalserver. Der alte Server hatte 64GB RAM und drehende Festplatten.

Wir haben im letzten Sommer neue Hardware hingestellt. Ebenfalls einen HPE-Server mit 128GB RAM und SSDs. Die VMs wurden direkt in den PVE importiert und die VirtIO-Treiber sowie der QUEMU-Guest-Agent sind alle installiert. Die VM-Tools sind deinstalliert.
In den Hardwareeinstellungen ist der Storage-Controller auf VirtIO-SCSI single eingestellt und die Netzwerkkarten haben auch alle den VirtIO-Treiber am Laufen.

Die Anwender klagen alle über ein deutlich langsameres System als vorher. Dadurch dass wir deutlich potentere Hardware haben, habe ich auch genügend RAM und Kerne spendiert. Wie gesagt, alle Komponenten laufen mit den VirtIO-Treibern (auch die Grafik).

Nun gehen mir die Argumente aus. Was mir auffiel: Der SWAP ist ständig im roten Bereich (siehe Screenshot). Woran mag das liegen? Andere Kunden mit ähnlicher Kombination haben eine SWAP-Auslastung im unteren Drittel. Wie und wo kann ich das beeinflussen?

 

[tk102]

Wie ist denn das Storage deines Servers konfiguriert ?
Gibt es einen Grund, warum du noch die 8.4.1 nutzt ?

 

[cklahn]

Wie ist denn das Storage deines Servers konfiguriert ?
Gibt es einen Grund, warum du noch die 8.4.1 nutzt ?

PVE selbst läuft auf einem HPE-Boot-Device. Das ist eine Steckkarte, auf der sich zwei NVMes befinden, die 1:1 gemirrort sind. Dateisystem ist ext4. Das Storage besteht aus SSDs, die als RAID10 unter zfs angelegt sind.

Bzgl. Upgrade auf die 9.x habe ich mich noch nicht getraut ;-). Gegenfrage: Was spricht gegen die 8.4.1?

 

[Impact]

Die Hardware Info der VM und Ausgabe von arc_summary -s und pvenode config get --property ballooning-target wären ganz interessant. Langsam ist auch etwas vaage. Was genau ist langsam?
Zum Thema SWAP ist das vielleicht hilfreich
- https://gist.github.com/Impact123/3dbd7e0ddaf47c5539708a9cbcaab9e3#monitor-swap-usage
- https://chrisdown.name/2018/01/02/in-defence-of-swap.html
top kann SWAP auch pro Prozess anzeigen und sortieren wenn man f drückt und die Spalte aktiviert.

 

[mac.linux.free]

https://www.softec.de/2025/03/13/performanceprobleme-mit-windows-10-und-11-beheben/

Das Script hat bei mir bei allen TSn geholfen.

 

[cklahn]

Hallo
ich habe das Skript mal heruntergeladen und geöffnet. In einer der ersten Zeilen ist eine Verlinkung auf einen Bericht drin. In diesem Bericht steht:

"Das Script muss mit Administratorberechtigungen ausgeführt werden, da es andernfalls zu Fehlern kommt. Es ist laut Fuchs nur für die Optimierung von Windows 10/11 gedacht und sollte nicht auf einem Server-Betriebssystem ausgeführt werden."

Da ich einen Terminal-Server habe, passt es leider nicht.

 

[mac.linux.free]

Es geht bei mir sogar auf einem 2025er Server. Also klappt es wunderbar. Grüße.

 

[boisbleu]

Es fehlen immer noch die Details zur VM. So werden wir hier nicht weiter kommen. :-/

 

[Falk R.]

Hallo Forum,

ein Kunde hatte einen HPE-Server mit VMware und virtualisiertem DC, Exchange und Terminalserver. Der alte Server hatte 64GB RAM und drehende Festplatten.

Wir haben im letzten Sommer neue Hardware hingestellt. Ebenfalls einen HPE-Server mit 128GB RAM und SSDs. Die VMs wurden direkt in den PVE importiert und die VirtIO-Treiber sowie der QUEMU-Guest-Agent sind alle installiert. Die VM-Tools sind deinstalliert.
In den Hardwareeinstellungen ist der Storage-Controller auf VirtIO-SCSI single eingestellt und die Netzwerkkarten haben auch alle den VirtIO-Treiber am Laufen.

Die Anwender klagen alle über ein deutlich langsameres System als vorher. Dadurch dass wir deutlich potentere Hardware haben, habe ich auch genügend RAM und Kerne spendiert.

Ich glaube genau hier hast du dein Problem. RAM darfst du gern so viel geben wie du möchtest. Bei CPU Cores sollte man bei VMs sparsam sein und immer nur genau so viel geben wie benötigt. Bei Hardware hilft viel, immer viel. Bei VMs hat man schnell Überbuchungen und CPU Wartezeiten.

Teil mal das Sizing der VMs.
Bei der CPU solltest du sowieso nie mehr als 12 Cores einer VM geben, da es sonst mit Garantie langsam wird.

 

[showiproute]

Ich glaube genau hier hast du dein Problem. RAM darfst du gern so viel geben wie du möchtest. Bei CPU Cores sollte man bei VMs sparsam sein und immer nur genau so viel geben wie benötigt. Bei Hardware hilft viel, immer viel. Bei VMs hat man schnell Überbuchungen und CPU Wartezeiten.

Teil mal das Sizing der VMs.
Bei der CPU solltest du sowieso nie mehr als 12 Cores einer VM geben, da es sonst mit Garantie langsam wird.

Darf ich hier mal Offtopic nachfragen, warum man nicht mehr als 12 Cores einer VM zuweisen soll?

 

[cwt]

Mehr als X Kerne/vCPUs bezieht sich wahrscheinlich auf Multi Socket Systeme. Bei MCore würde ich persönlich CPUs pinnen, bspw. 0-11, damit die VM auf einer CPU bleibt.

 

[Falk R.]

Darf ich hier mal Offtopic nachfragen, warum man nicht mehr als 12 Cores einer VM zuweisen soll?

Es sind zwei 12 Core CPUs verbaut. Wenn man einer VM mehr als 12 Cores gibt wird entweder auf beide CPUs verteilt was immer NUMA Delay mit sich bringt, außer man hat eine NUMA Aware Anwendung und vNUMA konfiguriert.
Anderenfalls wird Hyperthread statt eigener Cores genutzt, was auch nicht so schnell ist wie native Cores, da ein Core mit seinen beiden Threads nur über einen Kanal angesprochen wird.
Außerdem kommt man mit so dicken VMs ganz schnell zu langen Warteschlangen bei den CPUs, da die Überprovisionierung steigt und eine 12 Core VM immer auf 12 freie Cores warten muss, auch wenn gerade nur ein paar MHz Leistung benötigt werden.