DirectDraw auf Server 2022 und VMware langsam
Moin,
ich bin gerade auf der Ursachensuche...
Problem:
Kunde migriert von Windows Server 2008R2 nach 2022, soweit so gut. Hypervisor in beiden Fällen VMware ESX 7.0 CU2 und ein paar Patches
Dabei ist aufgefallen, daß DirectDraw 75% seiner Leistung eingebüßt hat. Zunächst ist das in einer CAE Software aufgefallen, wenn die Punktwolken in 2D darstellt oder nicht vektorisierte Stempel oder Symbole zeichnet (das sind dann oft mal 50.000 einzelne Pixel) ist sie deutlich langsamer.
Das Verhalten war auf drei verschiedenen physischen Hosts mit verschiedenen VMware Versionen reproduzierbar.
Zwei Entwickler haben dann mit unterschiedlcihen Tests nachgewiesen... daß DirectDraw langsamer wird.
Programm 1: zeichnet ein paar Linien, auf Server 2008R2 ist das in einer Milisekunde erledigt, und läuft auch sehr konstant. Auf Server 2022 ist schon die Grundperformance bei 4 Milisekunden und schankt bis nach 30 ms.
Programm 2: zeichnet mit WPF (verwendet am Ende DirectX 9 / DirectDraw ) eine Graphik punktwiese , 1024x768, auch hier: 900 ms auf Server 2008R2 um das Bild punktweise mit dc.draw zu zeichnen und 5000-8000 ms um es auf Server 2022 zu machen
Ich hab das auf einem LAb mal durchgespielt und festgstellt daß VMware das DirectDraw generell auf Server 2019 und Server 2022 langsamer macht, egal ob ESX 6.7, 7.0 oder 8.0, auch unter HyperV muß man etwas "bezahlen". Nur auf HyperV hab ich nicht diese Schwankungen, sondern immer konstant ein langsameres Ergebnis, auf ESX ist das auch noch sehr stark schwankend. Allerdings war der Nachweis mit HyperV nur auf Azure nachweisbar da sich die IT aus Zeitmangel schlichtweg geweigert hat, das auch noch auf der On Premise Umgebung zuzulassen... auf Azure gabs einen Xeon Platinum 8370C, mit einer abscheulich schlechten Performance. 5 ms für den einen Usecase und 6000 ms für den anderen.
Dann später auf einem LAb Server 2022 physisch installiert - maximale Performance per RDP, eine Milisekunde für den einen USecase und 900 für den anderen. Es liegt also nicht am OS an sich, aber als Gast in einer Virtualisierung schon, in etwas abgeschwächter Form ist es auch auf Server 2019 beobachtbar.
Nur wie kriegt man das in den Griff?
Ist das Problem bekannt?
Ich bin mir relativ sicher, daß Microsoft was am Speichermanagement der virtuellen Graphikkarte im RDP-Betrieb geändert hat, und zwar ab Server 2019. Etwas, was am Ende Schreiboperationen in den Speicher der Terminalserverfunktionalität "teuer" macht, z.B. durch misalinged Speicherzugriffe, cold cache wegen fehlerhafter MMU Zuweisung von virutellem zu physischem Speicher (hier spielt dann das IOMMU des Mainboards noch eine Rolle), oder das 2 MB Speicherblockmodell? Das gabs genaugenommen auch schon auf Server 2008r2.
ich bin gerade auf der Ursachensuche...
Problem:
Kunde migriert von Windows Server 2008R2 nach 2022, soweit so gut. Hypervisor in beiden Fällen VMware ESX 7.0 CU2 und ein paar Patches
Dabei ist aufgefallen, daß DirectDraw 75% seiner Leistung eingebüßt hat. Zunächst ist das in einer CAE Software aufgefallen, wenn die Punktwolken in 2D darstellt oder nicht vektorisierte Stempel oder Symbole zeichnet (das sind dann oft mal 50.000 einzelne Pixel) ist sie deutlich langsamer.
Das Verhalten war auf drei verschiedenen physischen Hosts mit verschiedenen VMware Versionen reproduzierbar.
Zwei Entwickler haben dann mit unterschiedlcihen Tests nachgewiesen... daß DirectDraw langsamer wird.
Programm 1: zeichnet ein paar Linien, auf Server 2008R2 ist das in einer Milisekunde erledigt, und läuft auch sehr konstant. Auf Server 2022 ist schon die Grundperformance bei 4 Milisekunden und schankt bis nach 30 ms.
Programm 2: zeichnet mit WPF (verwendet am Ende DirectX 9 / DirectDraw ) eine Graphik punktwiese , 1024x768, auch hier: 900 ms auf Server 2008R2 um das Bild punktweise mit dc.draw zu zeichnen und 5000-8000 ms um es auf Server 2022 zu machen
Ich hab das auf einem LAb mal durchgespielt und festgstellt daß VMware das DirectDraw generell auf Server 2019 und Server 2022 langsamer macht, egal ob ESX 6.7, 7.0 oder 8.0, auch unter HyperV muß man etwas "bezahlen". Nur auf HyperV hab ich nicht diese Schwankungen, sondern immer konstant ein langsameres Ergebnis, auf ESX ist das auch noch sehr stark schwankend. Allerdings war der Nachweis mit HyperV nur auf Azure nachweisbar da sich die IT aus Zeitmangel schlichtweg geweigert hat, das auch noch auf der On Premise Umgebung zuzulassen... auf Azure gabs einen Xeon Platinum 8370C, mit einer abscheulich schlechten Performance. 5 ms für den einen Usecase und 6000 ms für den anderen.
Dann später auf einem LAb Server 2022 physisch installiert - maximale Performance per RDP, eine Milisekunde für den einen USecase und 900 für den anderen. Es liegt also nicht am OS an sich, aber als Gast in einer Virtualisierung schon, in etwas abgeschwächter Form ist es auch auf Server 2019 beobachtbar.
Nur wie kriegt man das in den Griff?
Ist das Problem bekannt?
Ich bin mir relativ sicher, daß Microsoft was am Speichermanagement der virtuellen Graphikkarte im RDP-Betrieb geändert hat, und zwar ab Server 2019. Etwas, was am Ende Schreiboperationen in den Speicher der Terminalserverfunktionalität "teuer" macht, z.B. durch misalinged Speicherzugriffe, cold cache wegen fehlerhafter MMU Zuweisung von virutellem zu physischem Speicher (hier spielt dann das IOMMU des Mainboards noch eine Rolle), oder das 2 MB Speicherblockmodell? Das gabs genaugenommen auch schon auf Server 2008r2.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 43755838811
Url: https://administrator.de/contentid/43755838811
Ausgedruckt am: 21.11.2024 um 15:11 Uhr
1 Kommentar