9
Wie viele vCore pro Terminal Server?
Moin
Kurz vorweg: Ich versuche die für meine Umgebung optimale vCore-Ausstattung für neu installierte Terminal Server zu ermitteln. CPU overcommitment muss natürlich vermieden/verhindert werden, ich möchte aber auch nicht das Leistung einfach brach liegt. Wir sind extra von zwei "dicken" Terminal Server auf vier etwas kleinere gewechselt damit der Scheduler flexibel bleibt.
Ich kann leider kein Hot-Add CPU nutzen, sonst könnte ich das gut testen. Jeder Neustart der Terminal Server ist aber eine Qual weil dann alle Anwendungen langsamm laufen. Daher kann ich jetzt nicht gut viele Tests machen.
Hardware CPU dual Xeon Gold 6154 a 18 pCore + HT = 72 pCore pro Host
ALT-Zustand 2x Windows 2012 R2 VM als RD-SH a 16 vCore + 128 GB RAM, also ein RD-SH pro Host
NEU-Zustand 4x Windows 2019 VM als RD-SH a 12 vCore + 64 GB RAM, also zwei RD-SH pro Host
Wir haben unsere Terminal Server von Windows 2012 R2 auf 2019 gebracht und die 2019 Server diese Woche in den produktiven Betrieb genommen. Derzeit sind ~27 User auf drei der vier RD-SH zugange. Gleichzeitig sind noch 32 weitere VMs online. Ich habe die Ressourcen erstmal etwas zurückhalten zugewiesen weil ich sehen will wie sich das ganze verhält. Eigentlich sollte das aber ausreichen und eigentlich tut es das aus meiner Sicht auch. Unter Windows sind die Server relativ konstant unter 30% CPU aber es kommt eben auch mal zu kurzen Phasen wo ein Server ein bisschen was zu tun bekommt.
Nur, es läuft irgendwie noch nicht richtig rund. Ich kann das gar nicht erklären, hier mal zwei Beispiele:
- Anwender startet Programm, lädt sehr lange, nächster Start schnell. Das trat früher schon auf immer dann wenn der Server neu gestartet wurde. Das ist aber teilweise extrem, bis zu 10 Minuten, früher war das bei weitem nicht so heftig. Und vor allem ist das gar nicht immer reproduzierbar, noch ein Neustart, Anmeldung, Programmstart alles okay. Ich traue mich im Moment gar nicht die Dinger Abends durch zu starten.
- Anwender startet Programm, friert ein / reagiert nicht. Beenden über Taskmanager, dannach immer noch das selbe. Meldet sich der Benutzer neu an geht wieder alles. Das ist jetzt heute bei zwei von den 27 Anwendern auf zwei verschiedenen Hosts mit drei verschiedenen Programmen passiert.
Ich habe mir jetzt seit Jahren mal wieder esxtop gekrallt. Eigentlich sehr spannend, leider habe ich auch nicht die Zeit damit die Megaanalysen zu fahren. Ein paar Sachen sind mir aufgefallen:
- Die %-Auslastung der beiden CPUs in der obersten Zeile liegt entweder bei 17-23% (beide gleichzeitig) oder bei 3-10% (beide gleichzeitig), selten dazwischen. Da kann ich mir noch nicht so einen Reim drauf machen, ist aber vielleicht auch völlig i.O.
- CPU overcommitment ist derzeit eher nicht der Fall. Wenn ich das richtig verstehe würde sich das Äußern in dem %USED und %RDY beide hoch laufen, siehe hier:
https://subscription.packtpub.com/book/cloud-and-networking/978178646462 ...
oder %CSTP austickt, siehe hier:
http://blog.zorangagic.com/2015/04/vsphere-cpu-overcommitment-cpu-ready ...
%CSTP ist bei mir immer 0.00
%USED lag in der Spitze für einen RD-SH bei 770, entspricht das dann 770% von 72 pCore / 7200% * 2,99 GHz?
%RDY liegt bei mir etwa zwischen 1 und 1.5, selten mal bei 2,5.
Und nun die Frage, CPU vCore weiter rauf? Wo ist eine sinnvolle Grenze seitens VMware (vielleicht 50% aller pCore einer pCPU)? Habt ihr Erfahrungswerte wieviele User und wieviele vCores so eine RD-SH VM haben sollte?
Kurz vorweg: Ich versuche die für meine Umgebung optimale vCore-Ausstattung für neu installierte Terminal Server zu ermitteln. CPU overcommitment muss natürlich vermieden/verhindert werden, ich möchte aber auch nicht das Leistung einfach brach liegt. Wir sind extra von zwei "dicken" Terminal Server auf vier etwas kleinere gewechselt damit der Scheduler flexibel bleibt.
Ich kann leider kein Hot-Add CPU nutzen, sonst könnte ich das gut testen. Jeder Neustart der Terminal Server ist aber eine Qual weil dann alle Anwendungen langsamm laufen. Daher kann ich jetzt nicht gut viele Tests machen.
Hardware CPU dual Xeon Gold 6154 a 18 pCore + HT = 72 pCore pro Host
ALT-Zustand 2x Windows 2012 R2 VM als RD-SH a 16 vCore + 128 GB RAM, also ein RD-SH pro Host
NEU-Zustand 4x Windows 2019 VM als RD-SH a 12 vCore + 64 GB RAM, also zwei RD-SH pro Host
Wir haben unsere Terminal Server von Windows 2012 R2 auf 2019 gebracht und die 2019 Server diese Woche in den produktiven Betrieb genommen. Derzeit sind ~27 User auf drei der vier RD-SH zugange. Gleichzeitig sind noch 32 weitere VMs online. Ich habe die Ressourcen erstmal etwas zurückhalten zugewiesen weil ich sehen will wie sich das ganze verhält. Eigentlich sollte das aber ausreichen und eigentlich tut es das aus meiner Sicht auch. Unter Windows sind die Server relativ konstant unter 30% CPU aber es kommt eben auch mal zu kurzen Phasen wo ein Server ein bisschen was zu tun bekommt.
Nur, es läuft irgendwie noch nicht richtig rund. Ich kann das gar nicht erklären, hier mal zwei Beispiele:
- Anwender startet Programm, lädt sehr lange, nächster Start schnell. Das trat früher schon auf immer dann wenn der Server neu gestartet wurde. Das ist aber teilweise extrem, bis zu 10 Minuten, früher war das bei weitem nicht so heftig. Und vor allem ist das gar nicht immer reproduzierbar, noch ein Neustart, Anmeldung, Programmstart alles okay. Ich traue mich im Moment gar nicht die Dinger Abends durch zu starten.
- Anwender startet Programm, friert ein / reagiert nicht. Beenden über Taskmanager, dannach immer noch das selbe. Meldet sich der Benutzer neu an geht wieder alles. Das ist jetzt heute bei zwei von den 27 Anwendern auf zwei verschiedenen Hosts mit drei verschiedenen Programmen passiert.
Ich habe mir jetzt seit Jahren mal wieder esxtop gekrallt. Eigentlich sehr spannend, leider habe ich auch nicht die Zeit damit die Megaanalysen zu fahren. Ein paar Sachen sind mir aufgefallen:
- Die %-Auslastung der beiden CPUs in der obersten Zeile liegt entweder bei 17-23% (beide gleichzeitig) oder bei 3-10% (beide gleichzeitig), selten dazwischen. Da kann ich mir noch nicht so einen Reim drauf machen, ist aber vielleicht auch völlig i.O.
- CPU overcommitment ist derzeit eher nicht der Fall. Wenn ich das richtig verstehe würde sich das Äußern in dem %USED und %RDY beide hoch laufen, siehe hier:
https://subscription.packtpub.com/book/cloud-and-networking/978178646462 ...
oder %CSTP austickt, siehe hier:
http://blog.zorangagic.com/2015/04/vsphere-cpu-overcommitment-cpu-ready ...
%CSTP ist bei mir immer 0.00
%USED lag in der Spitze für einen RD-SH bei 770, entspricht das dann 770% von 72 pCore / 7200% * 2,99 GHz?
%RDY liegt bei mir etwa zwischen 1 und 1.5, selten mal bei 2,5.
%RDY – %RDY or CPU Ready percentage is the metric that describes the amount of time a virtual machine waits in the queue in a ready-to-run state before it can be scheduled on a pCPU. The lower %RDY metric the better and the generally acceptable threshold is around 10% but aim for 5% or less.
Und nun die Frage, CPU vCore weiter rauf? Wo ist eine sinnvolle Grenze seitens VMware (vielleicht 50% aller pCore einer pCPU)? Habt ihr Erfahrungswerte wieviele User und wieviele vCores so eine RD-SH VM haben sollte?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 8179816754
Url: https://administrator.de/contentid/8179816754
Ausgedruckt am: 18.12.2024 um 21:12 Uhr
9 Kommentare
Neuester Kommentar
Moin...
wenn es Datev oder Outlook ist, wird es eher ein Bandbreiten Problem (Netzwerk) sein! hast du den Defender rausgeworfen, und das Netzwerk Optimiert? im SQL bereich (Datev) bringt das schon gerne mal Probleme!
passiert das morgens, wenn alle ihren login machen?
ich habe teilweise RDS Host, die mit 30 Usern Arbeiten, 16 vCore 64-96GB Ram und als unterbau samsung pm1735, die machen 8000 MBps (lesen)/ 3800 MBps (Schreiben)! Anwendungen sind MS Office Outlook und Pipedrive (Google Chrome)
der Datev RDS Host, braucht ein wenig mehr leistung, und haben in der regel für 15 User am Laufen, mit bis zu 20 vCPU und 64- 96GB Ram! mit FSLogix gab es da teilweise Probleme beim Laden der Profile im Netz - deswegen liegen die jetzt local auf dem Host, auf samsung 1735 NVMe...
Eine Diskussion zu RDP bei Windows Server 2022
Frank
- Anwender startet Programm, friert ein / reagiert nicht. Beenden über Taskmanager, dannach immer noch das selbe. Meldet sich der Benutzer neu an geht wieder alles. Das ist jetzt heute bei zwei von den 27 Anwendern auf zwei verschiedenen Hosts mit drei verschiedenen Programmen passiert.
wenn es Datev oder Outlook ist, wird es eher ein Bandbreiten Problem (Netzwerk) sein! hast du den Defender rausgeworfen, und das Netzwerk Optimiert? im SQL bereich (Datev) bringt das schon gerne mal Probleme!
passiert das morgens, wenn alle ihren login machen?
ich habe teilweise RDS Host, die mit 30 Usern Arbeiten, 16 vCore 64-96GB Ram und als unterbau samsung pm1735, die machen 8000 MBps (lesen)/ 3800 MBps (Schreiben)! Anwendungen sind MS Office Outlook und Pipedrive (Google Chrome)
der Datev RDS Host, braucht ein wenig mehr leistung, und haben in der regel für 15 User am Laufen, mit bis zu 20 vCPU und 64- 96GB Ram! mit FSLogix gab es da teilweise Probleme beim Laden der Profile im Netz - deswegen liegen die jetzt local auf dem Host, auf samsung 1735 NVMe...
Eine Diskussion zu RDP bei Windows Server 2022
Frank
1
Moin ukulele-7,
zuerst zu dem vCPU Thema.
Du solltest bei VM's generell nicht mehr wie 8 vCore's verwenden, da ab 8 vCores der Overhead für das Core Scheduling unerträglich hoch wird.
Dein Problem sind übrigens nicht wirklich die vCores sondern eher der Server 2019, denn dieser verhält sich bei ganz vielen Situationen, leider ganz anders wie ein Server 2012R2. 😔
Habe zu diesem Thema schon diverseste Romane geschrieben.
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
Du könntest innerhalb der VM mein Optimierungsskript für W10/W11 durchlaufen lassen, dass sollte das eine oder andere Problem bereits mindern. 😉
https://github.com/MysticFoxDE/WINDOWS-OPTIMIZATIONS/blob/main/W10ANDW11 ...
+
Das ist aber nur ein kleiner Teil dessen, was bei einem WS2019 optimiert werden muss.
Wir können gerne die anderen Punkte Schritt für Schritt über das Forum abarbeiten, jedoch wird das erfahrungsgemäss eine längere und kompliziertere Geschichte.
Optimaler wäre schon z.B. eine TeamViewer Sitzung. Dann könnte ich das was ich an Infos benötige selber schnell zusammensuchen und dir im Anschluss sagen, was du an deiner Umgebung noch alles nachoptimieren musst.
Gruss Alex
zuerst zu dem vCPU Thema.
Du solltest bei VM's generell nicht mehr wie 8 vCore's verwenden, da ab 8 vCores der Overhead für das Core Scheduling unerträglich hoch wird.
Dein Problem sind übrigens nicht wirklich die vCores sondern eher der Server 2019, denn dieser verhält sich bei ganz vielen Situationen, leider ganz anders wie ein Server 2012R2. 😔
Habe zu diesem Thema schon diverseste Romane geschrieben.
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
Du könntest innerhalb der VM mein Optimierungsskript für W10/W11 durchlaufen lassen, dass sollte das eine oder andere Problem bereits mindern. 😉
https://github.com/MysticFoxDE/WINDOWS-OPTIMIZATIONS/blob/main/W10ANDW11 ...
+
netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global fastopen=disabled
netsh int tcp set global fastopenfallback=disabled
netsh int tcp set global hystart=disabled
netsh int tcp set global prr=disabledDas ist aber nur ein kleiner Teil dessen, was bei einem WS2019 optimiert werden muss.
Wir können gerne die anderen Punkte Schritt für Schritt über das Forum abarbeiten, jedoch wird das erfahrungsgemäss eine längere und kompliziertere Geschichte.
Optimaler wäre schon z.B. eine TeamViewer Sitzung. Dann könnte ich das was ich an Infos benötige selber schnell zusammensuchen und dir im Anschluss sagen, was du an deiner Umgebung noch alles nachoptimieren musst.
Gruss Alex
2
Moin Frank,
das sollte aber auch mit 8 vCores locker stemmbar sein.
Wir konfigurieren normalerweise die Session Hosts mit meistens 4 und bis max. 8 vCores und das reicht gut für ~20-25 User pro SH auch bei Datev. Ab ~25 User pro Host werden die SH problematisch, aber meistens nicht wegen der CPU Last, sondern wegen der stellenweise absolut bescheuerten Defaultkonfiguration des Server 2019 seitens Microsoft.
Das Problem lässt sich normalerweise beseitigen.
Die Farmen unserer Kunden laufen mittlerweile alle über "User Profile Disks", was im Grunde +- dasselbe ist wie FSLogix und haben damit eigentlich keine Probleme.
Übrigens, eines der Probleme verursacht beim Server 2019, aber auch bei den Clients, die mittlerweile absolut abartige MSS.
https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking ...
Beim Server 2012R2 und auch Windows XP, war diese noch bei 64K.
Und quasi von heute auf morgen hat Microsoft beschlossen, diese von 64K auf sagenhafte 1GByte hochzusetzen, sprich mal kurz um das 16384 fache anzuheben. 😱😭
Diese Microsoftianer in Redmond haben meiner Ansicht nach überhaupt kein Gefühl mehr für das wahre Leben und sehen nur noch BigData in irgend welchen Wolken. 😡
Gruss Alex
der Datev RDS Host, braucht ein wenig mehr leistung, und haben in der regel für 15 User am Laufen, mit bis zu 20 vCPU und 64- 96GB Ram!
das sollte aber auch mit 8 vCores locker stemmbar sein.
Wir konfigurieren normalerweise die Session Hosts mit meistens 4 und bis max. 8 vCores und das reicht gut für ~20-25 User pro SH auch bei Datev. Ab ~25 User pro Host werden die SH problematisch, aber meistens nicht wegen der CPU Last, sondern wegen der stellenweise absolut bescheuerten Defaultkonfiguration des Server 2019 seitens Microsoft.
mit FSLogix gab es da teilweise Probleme beim Laden der Profile im Netz - deswegen liegen die jetzt local auf dem Host, auf samsung 1735 NVMe...
Das Problem lässt sich normalerweise beseitigen.
Die Farmen unserer Kunden laufen mittlerweile alle über "User Profile Disks", was im Grunde +- dasselbe ist wie FSLogix und haben damit eigentlich keine Probleme.
Übrigens, eines der Probleme verursacht beim Server 2019, aber auch bei den Clients, die mittlerweile absolut abartige MSS.
https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking ...
Beim Server 2012R2 und auch Windows XP, war diese noch bei 64K.
Und quasi von heute auf morgen hat Microsoft beschlossen, diese von 64K auf sagenhafte 1GByte hochzusetzen, sprich mal kurz um das 16384 fache anzuheben. 😱😭
Diese Microsoftianer in Redmond haben meiner Ansicht nach überhaupt kein Gefühl mehr für das wahre Leben und sehen nur noch BigData in irgend welchen Wolken. 😡
Gruss Alex
3
Okay der Reihe nach. Ich bin natürlich grade mit 1000 Wehwechen zugange neben was weiß ich nicht noch alles an Dingen die hier grade abgehen (Umbaumaßnahmen, neue Mitarbeiter...) aber alles in allem läuft es relativ gut. Ich habe nur wenige wirklich nervige Probleme, bin nur etwas gestreest 
zum Thema vCore:
Ich habe mal ein Expiriment gemacht und alle vier RD-SH auf 18 vCore gestellt. Die Perfomance ist nicht merklich schlechter aber auch nicht merklich besser. In esxtop sieht man aber deutlich das das keine so gute Idee war, %RDY ist konstant höher, auch mal über 4 oder 5%, und schlägt auch mal weiter aus 7 bis 13%. Sogar %CSTP ließ sich mal zu einem Wert >0 hinreißen lassen aber extrem selten.
Grundsätzlich funktioniert es, gut ist es aber nicht. Eure Meinung weniger ist mehr teile ich grundsätzlich, allerdings hatte ich unter 2012 R2 bereits 16 vCore aufgrund der kleinen Anzahl von nur zwei Hosts bei ~35 Usern. Das wurde irgendwann erhöht und hat sich da auch positiv bemerkbar gemacht, das mehr Hosts besser ist weiß ich aber natürlich auch. 8 vCore finde ich auch am besten aber auch irgendwie ein bisschen arg wenig für RD-SH. Vor allem beobachte ich unter 2019 eine relativ hohe "Grundlast", gefühlt 25-30% schon bei 12 vCore. Ob das einen negativen Impact hat kann ich nicht sagen.
Auch jetzt mit 18 vCore geht die Grundlast nicht unter 9% bei grade einmal noch 4 Usern. INur ob ich auch mit sagen wir 40% Grundlast bei 8 vCore keine Auswirkung mehr merken würde bezweifel ich etwas. Ich werde 8 vCore auch mal testen, nur nicht gleich wieder alles neu starten.
Ich möchte einfach das User, die kurzzeitig richtig Leistung abrufen, diese auch bekommen können und will daher nicht zu eng kalkulieren. Notfalls gehe ich auch auf 6 RD-SH hoch wenn es sich nicht vermeiden lässt.
Wie würde sich denn eurer Meinung nach ein größerer Host mit mehr pCore auswirken, würdet ihr dennoch zu max 8 vCore pro VM raten? Wir wollen eventuell dieses Jahr unseren dritten, alten Host ablösen. Verhält sich der Scheduler abhängig zur Anzahl der pCores oder mag er einfach 2er Potenzen ?
@Vision2015
Du kennst mich schon zu gut, natürlich geht es im Schwerpunkt um DATEV und seine ~200 Anwendungen mit gefühlt 500 exe-Dateien die alle nach einem Windows Neustart sehr träge sind, was natürlich nervt. Aktuell macht mir AP Comfort sorgen, das ist irgendwie anders und immer langsam. Ich muss mal nochmal bei DATEV schauen, es kann etwas ganz banales sein wie z.B. die Tatsache das ich jetzt das Datenlaufwerk mit FQDN des Servers anspreche. Das werde ich mit DATEV klären. Wir hatten zuvor einen RD-SH vollwertig installiert da war nur der DATEV Server noch auf 2012 R2 und der Datenpfad "kürzer".
Ich habe letzte Nacht noch eine Änderung getätitgt von der ich mir sehr viel verspreche: Die FSLogix vhdx liegt jetzt im selben Subnetz wie die RD-SH, das sollte den Traffic auf der Firewall reduzieren und alles entlasten.
@MysticFoxDE
Wao du steckst tief drin, sehr tief. - Mein Wissen ist da eher basic. Vor allem Danke für das Angebot, ich komme gerne mal auf eine Fernwartung zurück (gerne auch auf Rechnung) - wie gesagt wenn sich der Trubel etwas gelegt hat nehme ich mir die Zeit.
Ich werde erstmal keine TCP Settings ändern aber ich werde mir das Script etwas genauer ansehen. Gilt das aus deiner Sicht genauso für 2022 wie für 2019 und ist das eher auf RD-SH sinnvoll anwendbar oder auch auf echte Server mit primär "Hintergrunddiensten"?
Das Script erstellt ein Backup aller Settings, gibt es auch ein "Rücksetzscript"?
zum Thema vCore:
Ich habe mal ein Expiriment gemacht und alle vier RD-SH auf 18 vCore gestellt. Die Perfomance ist nicht merklich schlechter aber auch nicht merklich besser. In esxtop sieht man aber deutlich das das keine so gute Idee war, %RDY ist konstant höher, auch mal über 4 oder 5%, und schlägt auch mal weiter aus 7 bis 13%. Sogar %CSTP ließ sich mal zu einem Wert >0 hinreißen lassen aber extrem selten.
Grundsätzlich funktioniert es, gut ist es aber nicht. Eure Meinung weniger ist mehr teile ich grundsätzlich, allerdings hatte ich unter 2012 R2 bereits 16 vCore aufgrund der kleinen Anzahl von nur zwei Hosts bei ~35 Usern. Das wurde irgendwann erhöht und hat sich da auch positiv bemerkbar gemacht, das mehr Hosts besser ist weiß ich aber natürlich auch. 8 vCore finde ich auch am besten aber auch irgendwie ein bisschen arg wenig für RD-SH. Vor allem beobachte ich unter 2019 eine relativ hohe "Grundlast", gefühlt 25-30% schon bei 12 vCore. Ob das einen negativen Impact hat kann ich nicht sagen.
Auch jetzt mit 18 vCore geht die Grundlast nicht unter 9% bei grade einmal noch 4 Usern. INur ob ich auch mit sagen wir 40% Grundlast bei 8 vCore keine Auswirkung mehr merken würde bezweifel ich etwas. Ich werde 8 vCore auch mal testen, nur nicht gleich wieder alles neu starten.
Ich möchte einfach das User, die kurzzeitig richtig Leistung abrufen, diese auch bekommen können und will daher nicht zu eng kalkulieren. Notfalls gehe ich auch auf 6 RD-SH hoch wenn es sich nicht vermeiden lässt.
Wie würde sich denn eurer Meinung nach ein größerer Host mit mehr pCore auswirken, würdet ihr dennoch zu max 8 vCore pro VM raten? Wir wollen eventuell dieses Jahr unseren dritten, alten Host ablösen. Verhält sich der Scheduler abhängig zur Anzahl der pCores oder mag er einfach 2er Potenzen
?@Vision2015
Du kennst mich schon zu gut, natürlich geht es im Schwerpunkt um DATEV und seine ~200 Anwendungen mit gefühlt 500 exe-Dateien die alle nach einem Windows Neustart sehr träge sind, was natürlich nervt. Aktuell macht mir AP Comfort sorgen, das ist irgendwie anders und immer langsam. Ich muss mal nochmal bei DATEV schauen, es kann etwas ganz banales sein wie z.B. die Tatsache das ich jetzt das Datenlaufwerk mit FQDN des Servers anspreche. Das werde ich mit DATEV klären. Wir hatten zuvor einen RD-SH vollwertig installiert da war nur der DATEV Server noch auf 2012 R2 und der Datenpfad "kürzer".
Ich habe letzte Nacht noch eine Änderung getätitgt von der ich mir sehr viel verspreche: Die FSLogix vhdx liegt jetzt im selben Subnetz wie die RD-SH, das sollte den Traffic auf der Firewall reduzieren und alles entlasten.
@MysticFoxDE
Wao du steckst tief drin, sehr tief. - Mein Wissen ist da eher basic. Vor allem Danke für das Angebot, ich komme gerne mal auf eine Fernwartung zurück (gerne auch auf Rechnung) - wie gesagt wenn sich der Trubel etwas gelegt hat nehme ich mir die Zeit.
Ich werde erstmal keine TCP Settings ändern aber ich werde mir das Script etwas genauer ansehen. Gilt das aus deiner Sicht genauso für 2022 wie für 2019 und ist das eher auf RD-SH sinnvoll anwendbar oder auch auf echte Server mit primär "Hintergrunddiensten"?
Das Script erstellt ein Backup aller Settings, gibt es auch ein "Rücksetzscript"?
Moin @ukulele-7,
ich musste, sonst hätten unsere Kunden mir schon längst alle Haare vom Kopf gefressen und dass konnte ich nicht zulassen, weil ansonsten meinen beiden Hausdrachen nichts mehr übrig geblieben wäre. 🤪
Ja, leider, beim 2022 muss man sogar einen Ticken mehr berücksichtigen/optimieren. 😔
Das ist nur ein Teil der Optimierung, die wir mittlerweile auf so gut wie allen Windows Servern =>2019 machen müssen damit diese halbwegs performant laufen und unseren Kunden nicht zu viele Haare durch deren immer grösser werdenden Overhead, vom Kopf fressen. 😭
Jup.
https://github.com/MysticFoxDE/WINDOWS-OPTIMIZATIONS/blob/main/W10ANDW11 ...
Zu dem was du weiter oben über die Grundlast geschrieben hast ... 👍👍👍 ... du bist auf dem richtigen weg und ja, diese ist bei Server 2019 und auch 2022 deutlich höher als bei den Vorgänger. Die Gründe dafür sind aber sehr unterschiedlich. Zum einen liegt es an der immer schlechter werdenden Standardkonfiguration von MS, zum anderen an den immer mehr werdenden und per Default eingeschalteten Features, die für die meisten jedoch absolut Sinnlos bis extrem störend sind, u.s.w.
Auf was laufen deine HV's, VMware oder Hyper-V?
Und glaub mir, wenn das Windows gut optimiert ist, dann reichen dir 8 vCores pro RDS-SH für bis 25 User sehr gut aus.
Übrigens, dein Datev und wahrscheinlich auch die meisten anderen Anwendungen, profitieren eher von einem hohen Tackt, als von der Anzahl der Kerne selber.
Sprich, lieber in den HV's eine hoch getackerte CPU mit weniger Kernen verwenden, als eine mit niedrigem Tackt und vielen Kernen. 😉
Gruss Alex
Wao du steckst tief drin, sehr tief.
ich musste, sonst hätten unsere Kunden mir schon längst alle Haare vom Kopf gefressen und dass konnte ich nicht zulassen, weil ansonsten meinen beiden Hausdrachen nichts mehr übrig geblieben wäre. 🤪
Gilt das aus deiner Sicht genauso für 2022 wie für 2019
Ja, leider, beim 2022 muss man sogar einen Ticken mehr berücksichtigen/optimieren. 😔
und ist das eher auf RD-SH sinnvoll anwendbar oder auch auf echte Server mit primär "Hintergrunddiensten"?
Das ist nur ein Teil der Optimierung, die wir mittlerweile auf so gut wie allen Windows Servern =>2019 machen müssen damit diese halbwegs performant laufen und unseren Kunden nicht zu viele Haare durch deren immer grösser werdenden Overhead, vom Kopf fressen. 😭
Das Script erstellt ein Backup aller Settings, gibt es auch ein "Rücksetzscript"?
Jup.
https://github.com/MysticFoxDE/WINDOWS-OPTIMIZATIONS/blob/main/W10ANDW11 ...
Zu dem was du weiter oben über die Grundlast geschrieben hast ... 👍👍👍 ... du bist auf dem richtigen weg und ja, diese ist bei Server 2019 und auch 2022 deutlich höher als bei den Vorgänger. Die Gründe dafür sind aber sehr unterschiedlich. Zum einen liegt es an der immer schlechter werdenden Standardkonfiguration von MS, zum anderen an den immer mehr werdenden und per Default eingeschalteten Features, die für die meisten jedoch absolut Sinnlos bis extrem störend sind, u.s.w.
Auf was laufen deine HV's, VMware oder Hyper-V?
Und glaub mir, wenn das Windows gut optimiert ist, dann reichen dir 8 vCores pro RDS-SH für bis 25 User sehr gut aus.
Übrigens, dein Datev und wahrscheinlich auch die meisten anderen Anwendungen, profitieren eher von einem hohen Tackt, als von der Anzahl der Kerne selber.
Sprich, lieber in den HV's eine hoch getackerte CPU mit weniger Kernen verwenden, als eine mit niedrigem Tackt und vielen Kernen. 😉
Gruss Alex
@Alpe-IT hatte hier noch per PM geantwortet:
Das meine aktuell 18 vCore zuviel sind kann ich am %RDY ablesen wobei "leuchtet" etwas relativ ist, es geht ansich. Ich senke das aber dennoch ab nur ob 8 besser ist als 12 das kann ich noch nicht beurteilen.
Das Storage ist sicherlich nicht das geilste, das ist noch HDD. Es geht aber um eine Terminal Server VM, nichts mit SQL drauf.
Moin Moin,
Leider funktioniert die Chat Funktion in deinem Beitrag nicht.
Unter VMware ESXI kannst du massig Kerne verwenden.
Laut VMware nimmst du deine vorhanden Kerne mit dem Multiplikator x5 bis x7
D.H: bei deinen 72 Kernen hast du locker 350 Kerne die du in VMs packen kannst bevor es überhaupt zu CPU Überlastung kommt.
Der Indikator hier für ist beim ESXI Host in der CPU Überwachung das "CPU Ready" Attribute
Wenn das anfängt aufzuleuchten, musst du mit den weiteren Kernen aufpassen
Aber für mich klingt es nicht nach einem CPU Problem
Sind das SQL Anwendungen die einfrieren ?
Läuft alles auf einen einzigen Datastore ?
Das mit der pCPU zu vCPU Ratio klingt ziemlich krass aber mag machbar sein. Mich beschäftigt aber vor allem die Frage wieviele vCPU sollte eine VM maximal haben, und da hätte ich jetzt angenommen das es auch da eine sinnvolle Relation zu pCore gibt, das lese ich aber noch nicht hier raus.Leider funktioniert die Chat Funktion in deinem Beitrag nicht.
Unter VMware ESXI kannst du massig Kerne verwenden.
Laut VMware nimmst du deine vorhanden Kerne mit dem Multiplikator x5 bis x7
D.H: bei deinen 72 Kernen hast du locker 350 Kerne die du in VMs packen kannst bevor es überhaupt zu CPU Überlastung kommt.
Der Indikator hier für ist beim ESXI Host in der CPU Überwachung das "CPU Ready" Attribute
Wenn das anfängt aufzuleuchten, musst du mit den weiteren Kernen aufpassen
Aber für mich klingt es nicht nach einem CPU Problem
Sind das SQL Anwendungen die einfrieren ?
Läuft alles auf einen einzigen Datastore ?
Das meine aktuell 18 vCore zuviel sind kann ich am %RDY ablesen wobei "leuchtet" etwas relativ ist, es geht ansich. Ich senke das aber dennoch ab nur ob 8 besser ist als 12 das kann ich noch nicht beurteilen.
Das Storage ist sicherlich nicht das geilste, das ist noch HDD. Es geht aber um eine Terminal Server VM, nichts mit SQL drauf.
Zitat von @MysticFoxDE:
Ja, leider, beim 2022 muss man sogar einen Ticken mehr berücksichtigen/optimieren. 😔
Das ist nur ein Teil der Optimierung, die wir mittlerweile auf so gut wie allen Windows Servern =>2019 machen müssen damit diese halbwegs performant laufen und unseren Kunden nicht zu viele Haare durch deren immer grösser werdenden Overhead, vom Kopf fressen. 😭
Also wir haben jetzt 2022 DC Lizenzen angeschafft und wollen alles "wichtige" umstellen auf 2022, nur bei den RD-SH sind wir auf 2019 gegangen wegen Office mit Lizenz von M365, das war ja erst noch nicht frei gegeben, und wegen DATEV allgemein um da erstmal auf der sicheren Seite zu sein. Die CALs sind 2022.Gilt das aus deiner Sicht genauso für 2022 wie für 2019
Ja, leider, beim 2022 muss man sogar einen Ticken mehr berücksichtigen/optimieren. 😔
und ist das eher auf RD-SH sinnvoll anwendbar oder auch auf echte Server mit primär "Hintergrunddiensten"?
Das ist nur ein Teil der Optimierung, die wir mittlerweile auf so gut wie allen Windows Servern =>2019 machen müssen damit diese halbwegs performant laufen und unseren Kunden nicht zu viele Haare durch deren immer grösser werdenden Overhead, vom Kopf fressen. 😭
Dann werde ich wohl in Bezug auf alle meine neuen VMs mal dein Maßnahmenpaket prüfen müssen. Kann man das Script so blind testen?
Auf was laufen deine HV's, VMware oder Hyper-V?
VMware 7.0.3Übrigens, dein Datev und wahrscheinlich auch die meisten anderen Anwendungen, profitieren eher von einem hohen Tackt, als von der Anzahl der Kerne selber.
Sprich, lieber in den HV's eine hoch getackerte CPU mit weniger Kernen verwenden, als eine mit niedrigem Tackt und vielen Kernen. 😉
Das ist mir wohl bewusst, ist ein Xeon Gold 6154 3 bis 3,7 GHz und den habe ich wegen der single thread performance gewählt. Eventuell schaffen wir dieses Jahr noch eine Kiste an, ein Epyc 9274F 4,05 bis 4,3 GHz wäre reizvoll. Erstmal will ich aber die wichtigsten Migrationen über die Bühne bringen.Sprich, lieber in den HV's eine hoch getackerte CPU mit weniger Kernen verwenden, als eine mit niedrigem Tackt und vielen Kernen. 😉
Moin @ukulele-7,
Sowohl Datev, als auch O365 laufen beide unseren bisherigen Erfahrungen nach, auf einem Server 2022 absolut ohne Probleme. 😉
Ja, innerhalb einer VM mit klassischer vNIC Konfiguration, sollte das Script keine Probleme verursachen.
Es beinhaltet aber nicht alle Anpassungen, die vor allem auf einem Server >= 2019 notwendig sind, da ich es "nur" für die Optimierung der Clients erstellt habe.
Nice, bei VMware muss man zum Glück nicht so viel optimieren wie beim Hyper-V.
Hast du die Energieoptionen der ESXi auf Hochleistung gestellt?
👍👍👍, die flinken Biester kenne ich, haben wir auch schon mehrfach verbaut. 😁
Gruss Alex
Also wir haben jetzt 2022 DC Lizenzen angeschafft und wollen alles "wichtige" umstellen auf 2022, nur bei den RD-SH sind wir auf 2019 gegangen wegen Office mit Lizenz von M365, das war ja erst noch nicht frei gegeben, und wegen DATEV allgemein um da erstmal auf der sicheren Seite zu sein. Die CALs sind 2022.
Sowohl Datev, als auch O365 laufen beide unseren bisherigen Erfahrungen nach, auf einem Server 2022 absolut ohne Probleme. 😉
Dann werde ich wohl in Bezug auf alle meine neuen VMs mal dein Maßnahmenpaket prüfen müssen. Kann man das Script so blind testen?
Ja, innerhalb einer VM mit klassischer vNIC Konfiguration, sollte das Script keine Probleme verursachen.
Es beinhaltet aber nicht alle Anpassungen, die vor allem auf einem Server >= 2019 notwendig sind, da ich es "nur" für die Optimierung der Clients erstellt habe.
Auf was laufen deine HV's, VMware oder Hyper-V?
VMware 7.0.3Nice, bei VMware muss man zum Glück nicht so viel optimieren wie beim Hyper-V.
Hast du die Energieoptionen der ESXi auf Hochleistung gestellt?
Das ist mir wohl bewusst, ist ein Xeon Gold 6154 3 bis 3,7 GHz und den habe ich wegen der single thread performance gewählt.
👍👍👍, die flinken Biester kenne ich, haben wir auch schon mehrfach verbaut. 😁
Gruss Alex
Zitat von @MysticFoxDE:
Nice, bei VMware muss man zum Glück nicht so viel optimieren wie beim Hyper-V.
Hast du die Energieoptionen der ESXi auf Hochleistung gestellt?
Ja klar.Auf was laufen deine HV's, VMware oder Hyper-V?
VMware 7.0.3Nice, bei VMware muss man zum Glück nicht so viel optimieren wie beim Hyper-V.
Hast du die Energieoptionen der ESXi auf Hochleistung gestellt?
Das ist mir wohl bewusst, ist ein Xeon Gold 6154 3 bis 3,7 GHz und den habe ich wegen der single thread performance gewählt.
👍👍👍, die flinken Biester kenne ich, haben wir auch schon mehrfach verbaut. 😁
1
