10
Verbindung zu Windows RDS hakt sporadisch
Hallo zusammen,
ich habe seit einigen Wochen Probleme bei der Verbindung mit einem Windows RDS Host und bin langsam mit meinem Latein echt am Ende.
Folgender Aufbau:
- Windows Server 2022 Datacenter als VM installiert auf einem ESXi Host Version 7.0.2.
- Sophos Endpoint Protection als Virenschutz
- Die VM hat 28 virtuelle CPU Kerne und 112 GB Arbeitsspeicher zugewiesen.
- Der Hostserver ist per 10Gb/s Karte an einen 10G Switch angebunden.
- Virtueller Switch und virtuelle Netzwerkkarte laufen ebenfalls auf 10G mit dem VMXNET 3 Adapter
- Installiert wurde der Server letztes Jahr im April/ Mai.
Nun beklagen sich die User über eine Verbindung, die immer wieder hakt. Heißt es wird z.B. etwas getippt und die Zeichen erscheinen dann erst 1-2 Sekunden später auf dem Server, währenddessen komplettes Standbild.
Das passiert mehrmals täglich zu zufälligen Zeiten seit ein paar Wochen, kann also auch nur schlecht nachgestellt werden.
Zu dieser Zeit wurde nichts am Server oder am Netzwerk geändert, sodass ich mir nicht erklären kann woher der Fehler kommt.
Allgemein scheint der Server mir etwas "träge", auch in der Darstellung. Wenn man beispielsweise ein Fenster öffnet oder schließt sieht man keine fließende Bewegung der jeweiligen Animation, sondern es stockt teilweise.
Hierbei ist es auch egal, ob nur einer, oder zehn User angemeldet sind, die Auslastung ist auch im Durchschnitt bei 20-30%.
Zudem ist es auch egal, ob der Client per WLAN, Kabel oder VPN auf dem Server arbeitet.
Was ich schon alles versucht habe:
- Anpassen der Energieeinstellungen, alles auf Höchstleistung
- IPv6 per Registry deaktiviert & zusätzlich die Priorisierung von IPv4 erzwungen
- Deaktivierung von CUBIC auf der Netzwerkkarte (das hat wohl bei Server 2019 Probleme mit RDS gemacht)
- Die RDP Verbindung per GPO auf ausschließlich TCP umgestellt
- 1GB Netzwerkkarte zugewiesen und getestet, hier kommt der Fehler auch vor
- Aktuelle VMWare Tools installiert (Juli 2024) um die Treiber der Netzwerkkarte zu aktualisieren
- Deinstallation von Sophos Endpoint
Interessanterweise habe ich in einem anderen Beitrag über ein ähnliches Fehlerbild mit einem 2019er Server gelesen. Der/ Die damalige Ersteller*in hat berichtet, dass der Netzwerkdurchsatz nach Installation der RDS Rolle deutlich gesunken ist. Bei einem Testserver war wohl nach der Deinstallation der Rolle wieder wie vorher.
Ich habe nun noch keinen Testserver erstellt, aber konnte bei einem anderen Server 2022 Datacenter (Installiert auf dem selben ESXi Host) ähnliches Feststellen. Der Durchsatz beim Kopieren von größeren Dateien im Netzwerk ist hier doppelt so hoch wie auf dem RDS Host!
Leider habe ich bereits alle Beiträge mit gleichen oder ähnlichen Fehlerbildern durchforstet und bin bis jetzt noch nicht zu einer Lösung gekommen.
Ich hoffe hier hat noch jemand einen Tipp oder eine Idee für mich.
Falls noch mehr Infos nötig sind, fragt gerne nach.
Vielen Dank schonmal!
Lucas
ich habe seit einigen Wochen Probleme bei der Verbindung mit einem Windows RDS Host und bin langsam mit meinem Latein echt am Ende.
Folgender Aufbau:
- Windows Server 2022 Datacenter als VM installiert auf einem ESXi Host Version 7.0.2.
- Sophos Endpoint Protection als Virenschutz
- Die VM hat 28 virtuelle CPU Kerne und 112 GB Arbeitsspeicher zugewiesen.
- Der Hostserver ist per 10Gb/s Karte an einen 10G Switch angebunden.
- Virtueller Switch und virtuelle Netzwerkkarte laufen ebenfalls auf 10G mit dem VMXNET 3 Adapter
- Installiert wurde der Server letztes Jahr im April/ Mai.
Nun beklagen sich die User über eine Verbindung, die immer wieder hakt. Heißt es wird z.B. etwas getippt und die Zeichen erscheinen dann erst 1-2 Sekunden später auf dem Server, währenddessen komplettes Standbild.
Das passiert mehrmals täglich zu zufälligen Zeiten seit ein paar Wochen, kann also auch nur schlecht nachgestellt werden.
Zu dieser Zeit wurde nichts am Server oder am Netzwerk geändert, sodass ich mir nicht erklären kann woher der Fehler kommt.
Allgemein scheint der Server mir etwas "träge", auch in der Darstellung. Wenn man beispielsweise ein Fenster öffnet oder schließt sieht man keine fließende Bewegung der jeweiligen Animation, sondern es stockt teilweise.
Hierbei ist es auch egal, ob nur einer, oder zehn User angemeldet sind, die Auslastung ist auch im Durchschnitt bei 20-30%.
Zudem ist es auch egal, ob der Client per WLAN, Kabel oder VPN auf dem Server arbeitet.
Was ich schon alles versucht habe:
- Anpassen der Energieeinstellungen, alles auf Höchstleistung
- IPv6 per Registry deaktiviert & zusätzlich die Priorisierung von IPv4 erzwungen
- Deaktivierung von CUBIC auf der Netzwerkkarte (das hat wohl bei Server 2019 Probleme mit RDS gemacht)
- Die RDP Verbindung per GPO auf ausschließlich TCP umgestellt
- 1GB Netzwerkkarte zugewiesen und getestet, hier kommt der Fehler auch vor
- Aktuelle VMWare Tools installiert (Juli 2024) um die Treiber der Netzwerkkarte zu aktualisieren
- Deinstallation von Sophos Endpoint
Interessanterweise habe ich in einem anderen Beitrag über ein ähnliches Fehlerbild mit einem 2019er Server gelesen. Der/ Die damalige Ersteller*in hat berichtet, dass der Netzwerkdurchsatz nach Installation der RDS Rolle deutlich gesunken ist. Bei einem Testserver war wohl nach der Deinstallation der Rolle wieder wie vorher.
Ich habe nun noch keinen Testserver erstellt, aber konnte bei einem anderen Server 2022 Datacenter (Installiert auf dem selben ESXi Host) ähnliches Feststellen. Der Durchsatz beim Kopieren von größeren Dateien im Netzwerk ist hier doppelt so hoch wie auf dem RDS Host!
Leider habe ich bereits alle Beiträge mit gleichen oder ähnlichen Fehlerbildern durchforstet und bin bis jetzt noch nicht zu einer Lösung gekommen.
Ich hoffe hier hat noch jemand einen Tipp oder eine Idee für mich.
Falls noch mehr Infos nötig sind, fragt gerne nach.
Vielen Dank schonmal!
Lucas
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: 71931980223
Url: https://administrator.de/contentid/71931980223
Ausgedruckt am: 24.11.2024 um 12:11 Uhr
10 Kommentare
Neuester Kommentar
Moin,
Und wie viele physische Kerne sind vorhanden? 28 virtuelle Kerne ist viel zu viel. Bei mehr als 16 Kernen fängt es an, dass der Synchronisierungsaufwand den Geschwindigkeitszuwachs durch die höhere Anzahl an Kernen auffrisst. Das führt dann genau zu solchen Phänomenen, dass die Last zwar bei nominal 30% liegt (Taskmanager auf der Maschine), man aber das Gefühl hat, die Maschine liefe unter Volllast. Es ruckelt und wackelt.
Wie viele User sind es denn? Wenn die Anzahl der User so hoch ist, dann solltest Ihr überlegen, aus einem TS eine TS-Farm aus zwei oder drei Maschinen zu machen. Die können alle auf demselben ESXi laufen, sofern der genug physische Kapazitäten hat. Aber es läuft deutlich performanter, wenn Ihr z. B. vier Maschinen mit jeweils 6 Kernen habt als eine Maschine mit 28.
hth
Erik
Und wie viele physische Kerne sind vorhanden? 28 virtuelle Kerne ist viel zu viel. Bei mehr als 16 Kernen fängt es an, dass der Synchronisierungsaufwand den Geschwindigkeitszuwachs durch die höhere Anzahl an Kernen auffrisst. Das führt dann genau zu solchen Phänomenen, dass die Last zwar bei nominal 30% liegt (Taskmanager auf der Maschine), man aber das Gefühl hat, die Maschine liefe unter Volllast. Es ruckelt und wackelt.
Wie viele User sind es denn? Wenn die Anzahl der User so hoch ist, dann solltest Ihr überlegen, aus einem TS eine TS-Farm aus zwei oder drei Maschinen zu machen. Die können alle auf demselben ESXi laufen, sofern der genug physische Kapazitäten hat. Aber es läuft deutlich performanter, wenn Ihr z. B. vier Maschinen mit jeweils 6 Kernen habt als eine Maschine mit 28.
hth
Erik
2
Da brauche ich gar nicht alles lesen, die vCPU Konfiguration schreit mich gleich an. Die VM hat 28 Kerne? Wie viele hat der physische Host auf wie viele Sockets / NUMA Nodes verteilt? Das sieht mir sehr stark nach CPU overcommitment aus. Unter ESXi lässt sich das sehr gut mit esxtop nachvollziehen.
https://www.yellow-bricks.com/esxtop/
https://www.virten.net/vmware/esxtop/
https://www.computerweekly.com/de/tipp/Tipps-zum-Umgang-mit-dem-vCPU-Ove ...
Leider finde ich keinen richtig guten Artikel mehr zum Thema, hier im Forum wurde aber auch schon viel darüber diskutiert. Grundsätzlich würde ich jetzt erstmal davon ausgehen das deine VM viel zu viele vCore zugewiesen bekommen hat und mit sagen wir 10 oder 12 viel besser laufen wird und keine Lags mehr hat. Dazu unbedingt mal esxtop anschmeißen und %RDY begutachten.
https://www.yellow-bricks.com/esxtop/
https://www.virten.net/vmware/esxtop/
https://www.computerweekly.com/de/tipp/Tipps-zum-Umgang-mit-dem-vCPU-Ove ...
Leider finde ich keinen richtig guten Artikel mehr zum Thema, hier im Forum wurde aber auch schon viel darüber diskutiert. Grundsätzlich würde ich jetzt erstmal davon ausgehen das deine VM viel zu viele vCore zugewiesen bekommen hat und mit sagen wir 10 oder 12 viel besser laufen wird und keine Lags mehr hat. Dazu unbedingt mal esxtop anschmeißen und %RDY begutachten.
3
Hi @ukulele-7 , Hi @erikro ,
Eure Vermutung könnte tatsächlich richtig sein.
Ich bin gerade selbst etwas verblüfft, warum hier 28 Kerne zugewiesen sind. Auch wenn der Host 48 logische Kerne hat, verbraucht das natürlich viel zu viele davon.
Der %RDY Wert liegt bei ca. 20 - 23 für den betroffenen Server. Laut deinen Artikeln sollte er möglichst niedrig sein.
Heißt ich stelle die virtuellen Kerne runter, am besten um die 12 und teste dann noch einmal, richtig?
LG
Eure Vermutung könnte tatsächlich richtig sein.
Ich bin gerade selbst etwas verblüfft, warum hier 28 Kerne zugewiesen sind. Auch wenn der Host 48 logische Kerne hat, verbraucht das natürlich viel zu viele davon.
Der %RDY Wert liegt bei ca. 20 - 23 für den betroffenen Server. Laut deinen Artikeln sollte er möglichst niedrig sein.
Heißt ich stelle die virtuellen Kerne runter, am besten um die 12 und teste dann noch einmal, richtig?
LG
mal den Windows Perfmon anwerfen und z.B. im Network Bereich die IPV4 Packetfehler und Retransmits beobachten, sowie die
es ist auch schon oft vorgekommen, daß Windows zuviel oder zuwenig Offloading auf der Netzwerkkarte gemacht hat. Ich hab mal ein Misalinginment beim RSS miterlebt, ESX 6.0 und tools RTM, da brach mit dem VMNET3 die Performance um 95% ein... RSS war da fehlerhaft im VMXNET3 implementiert, mit dem E1000 gings.
Behoben ca. ein halbes Jahr später mit einem VMware Tools Update,Workaround war in Windows das RSS abzuschalten. Gab noch andere Vorkommnisse in neueren Versionen, hatten auch mit dem Offloading zu tun.
es ist auch schon oft vorgekommen, daß Windows zuviel oder zuwenig Offloading auf der Netzwerkkarte gemacht hat. Ich hab mal ein Misalinginment beim RSS miterlebt, ESX 6.0 und tools RTM, da brach mit dem VMNET3 die Performance um 95% ein... RSS war da fehlerhaft im VMXNET3 implementiert, mit dem E1000 gings.
Behoben ca. ein halbes Jahr später mit einem VMware Tools Update,Workaround war in Windows das RSS abzuschalten. Gab noch andere Vorkommnisse in neueren Versionen, hatten auch mit dem Offloading zu tun.
1
Moin @GrueneSosseMitSpeck,
nur aus Neugierde, hattest du die RSS Probleme rein zufällig mit einer Broadcom NIC?
Gruss Alex
es ist auch schon oft vorgekommen, daß Windows zuviel oder zuwenig Offloading auf der Netzwerkkarte gemacht hat. Ich hab mal ein Misalinginment beim RSS miterlebt, ESX 6.0 und tools RTM, da brach mit dem VMNET3 die Performance um 95% ein... RSS war da fehlerhaft im VMXNET3 implementiert, mit dem E1000 gings.
nur aus Neugierde, hattest du die RSS Probleme rein zufällig mit einer Broadcom NIC?
Gruss Alex
Moin @NastyNase,
innerhalb einer VM reicht in 99% der Fälle auch die Standard-Edition.
👍
😧 ... warum um Himmels Willen 28 vCores, das ist wie die Kollegen schon angemerkt haben, absolut overdressed.
Die RDS unserer Kunden haben nie mehr wie 8 vCores.
Das alleine ist heutzutage leider nicht wirklich eine Garantie für mehr Performance. Denn die meisten => 10G NIC's musst du viel komplexer konfigurieren, damit die auch so effektiv laufen wie eine 1G NIC. 🙃😭
Abgesehen von der vCore Geschichte, sehe ich für dein Problem zwei weitere Gründe.
Zum einen könnte dir RSC(LRO) in die Suppe Spucken, das solltest du auf den VM's auf jeden Fall ausschalten ...
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.network ...
... am Besten auch gleich vollständig auf den entsprechenden ESXi Nodes.
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.network ...
Das nächste könnte z.B. sein, dass dir am RDS der RAM von diesem blöden Windows Standby-Memory/Block-Caching aufgefressen wird ...
... sprich, wenn die Probleme wieder auftreten, dann schau bitte im Taskmanager nach, wieviel freien RAM dem System tatsächlich noch zur Verfügung steht.
Und lass dich bitte nicht von der Einfärbung des Taskmanagers täuschen, den dieser zeigt die RAM Belegung durch das Windows Software Caching (Standby-Memory), genau in der selben Farbe an ...
... wie auch den den wirklich freien RAM. 😭🤢🤮
Gruss Alex
- Windows Server 2022 Datacenter als VM installiert auf einem ESXi Host Version 7.0.2.
innerhalb einer VM reicht in 99% der Fälle auch die Standard-Edition.
- Sophos Endpoint Protection als Virenschutz
👍
- Die VM hat 28 virtuelle CPU Kerne und 112 GB Arbeitsspeicher zugewiesen.
😧 ... warum um Himmels Willen 28 vCores, das ist wie die Kollegen schon angemerkt haben, absolut overdressed.
Die RDS unserer Kunden haben nie mehr wie 8 vCores.
- Der Hostserver ist per 10Gb/s Karte an einen 10G Switch angebunden.
Das alleine ist heutzutage leider nicht wirklich eine Garantie für mehr Performance. Denn die meisten => 10G NIC's musst du viel komplexer konfigurieren, damit die auch so effektiv laufen wie eine 1G NIC. 🙃😭
Nun beklagen sich die User über eine Verbindung, die immer wieder hakt. Heißt es wird z.B. etwas getippt und die Zeichen erscheinen dann erst 1-2 Sekunden später auf dem Server, währenddessen komplettes Standbild.
Das passiert mehrmals täglich zu zufälligen Zeiten seit ein paar Wochen, kann also auch nur schlecht nachgestellt werden.
Das passiert mehrmals täglich zu zufälligen Zeiten seit ein paar Wochen, kann also auch nur schlecht nachgestellt werden.
Abgesehen von der vCore Geschichte, sehe ich für dein Problem zwei weitere Gründe.
Zum einen könnte dir RSC(LRO) in die Suppe Spucken, das solltest du auf den VM's auf jeden Fall ausschalten ...
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.network ...
... am Besten auch gleich vollständig auf den entsprechenden ESXi Nodes.
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.network ...
Das nächste könnte z.B. sein, dass dir am RDS der RAM von diesem blöden Windows Standby-Memory/Block-Caching aufgefressen wird ...
... sprich, wenn die Probleme wieder auftreten, dann schau bitte im Taskmanager nach, wieviel freien RAM dem System tatsächlich noch zur Verfügung steht.
Und lass dich bitte nicht von der Einfärbung des Taskmanagers täuschen, den dieser zeigt die RAM Belegung durch das Windows Software Caching (Standby-Memory), genau in der selben Farbe an ...
... wie auch den den wirklich freien RAM. 😭🤢🤮
Gruss Alex
2
Moin,
Zu den vCores: siehe oben.
Wird der RDS eigentlich zyklisch neugestartet?
Wir, als Beispiel, starten des Nachts die RDS (Citrix VDA) neu. Dann sind alte Anmeldungen „weg“ und auch sonstig gecachtet Kram. Und dank VDA haben wir gleichzeitig den Effekt, dass wir den Server auf den bereitgestellten Stand immer zurücksetzen lassen. Solange, bis dass eine neue Version aus dem GoldenImage bereitgestellt wird.
Ich würde also
a) vCores runter drehen. Wir haben 6Cores je RDS (je mit ~15-20 User)
b) RDS aufteilen
c) RDS zyklisch rebooten
Zu den vCores: siehe oben.
Wird der RDS eigentlich zyklisch neugestartet?
Wir, als Beispiel, starten des Nachts die RDS (Citrix VDA) neu. Dann sind alte Anmeldungen „weg“ und auch sonstig gecachtet Kram. Und dank VDA haben wir gleichzeitig den Effekt, dass wir den Server auf den bereitgestellten Stand immer zurücksetzen lassen. Solange, bis dass eine neue Version aus dem GoldenImage bereitgestellt wird.
Ich würde also
a) vCores runter drehen. Wir haben 6Cores je RDS (je mit ~15-20 User)
b) RDS aufteilen
c) RDS zyklisch rebooten
1
Hallo zusammen,
vielen Dank für eure vielen Antworten!
Kurzes Update:
Ich habe die vCores am Dienstag Abend runtergeschraubt auf 12 Kerne.
Seitdem scheinen die Lags nicht mehr vorgekommen zu sein.
Manchmal sieht man den Wald vor lauter Bäumen nicht...
Ich melde mich nochmal, wenn wir das ein paar Tage beobachten konnten, aber bis jetzt scheint es zu funktionieren.
Zu den anderen Themen:
@em-pie Wir haben schon zwei RDS, der zweite lief deutlich performanter, hatte aber auch nur 12 Cores zugewiesen, da hier auch deutlich weniger User arbeiten. Die Aufteilung werde ich nach dem Sommer noch etwas ausgleichen.
Zyklische Neustarts machen wir zwar nicht täglich, aber wöchentlich.
Per Skript werden die User aber jeden Abend komplett abgemeldet, um den Cache besser in den Griff zu bekommen.
@MysticFoxDE Bezüglich RSC und RAM Block-Caching werde ich auch noch etwas recherchieren, wenn ich die Performance noch mehr verbessern kann, ist mir bestimmt auch niemand böse
Ich melde mich in ein paar Wochen nochmal mit einem aktuellen Stand. Bis dahin - Vielen Dank für eure Mühen, das hat mir echt weiter geholfen!
LG
Lucas
vielen Dank für eure vielen Antworten!
Kurzes Update:
Ich habe die vCores am Dienstag Abend runtergeschraubt auf 12 Kerne.
Seitdem scheinen die Lags nicht mehr vorgekommen zu sein.
Manchmal sieht man den Wald vor lauter Bäumen nicht...
Ich melde mich nochmal, wenn wir das ein paar Tage beobachten konnten, aber bis jetzt scheint es zu funktionieren.
Zu den anderen Themen:
@em-pie Wir haben schon zwei RDS, der zweite lief deutlich performanter, hatte aber auch nur 12 Cores zugewiesen, da hier auch deutlich weniger User arbeiten. Die Aufteilung werde ich nach dem Sommer noch etwas ausgleichen.
Zyklische Neustarts machen wir zwar nicht täglich, aber wöchentlich.
Per Skript werden die User aber jeden Abend komplett abgemeldet, um den Cache besser in den Griff zu bekommen.
@MysticFoxDE Bezüglich RSC und RAM Block-Caching werde ich auch noch etwas recherchieren, wenn ich die Performance noch mehr verbessern kann, ist mir bestimmt auch niemand böse
Ich melde mich in ein paar Wochen nochmal mit einem aktuellen Stand. Bis dahin - Vielen Dank für eure Mühen, das hat mir echt weiter geholfen!
LG
Lucas
Moin @NastyNase,
👍👍👍 👏👏👏
Gruss Alex
wenn ich die Performance noch mehr verbessern kann, ist mir bestimmt auch niemand böse
👍👍👍 👏👏👏
Gruss Alex
1
Ich habe in Erinnerung, das für %RDY ein Wert von maximal 5 empfohlen wird, wobei selbst das eigentlich eher hoch ist. Ich denke über 3 sollte er nur selten gehen, das kann man aber für sich am besten beobachten und entscheiden.
Auch, wie viele vCores es denn nun sein sollten, ist irgendwie Erfahrungsabhängig. Du sagst es gibt 48 pCores, leider aber nicht, wie sich die aufteilen. Ich denke, bis 8 vCores geht jeder mit. Ansonsten sicherlich nie mehr, als eine einzelne CPU im Blech hat, wegen NUMA & Co. Bei 48 pCores in einem 2 CPU System wären das also allerhöchstens 24. Das ist dann aber ein Wert den man machen kann wenn z.B. sonst nichts oder fast nichts auf dem Host los ist. Wenn es z.B. einen anderen RD-SH gibt mit der selben Konfiguration dann ist das natürlich auch viel zu viel. Alles, was an VMs durchgehend rechnen muss, sollte irgendwo auch alle seine vCores gleichzeitig bekommen können.
Und Verteilung auf mehrere RD-SH mit weniger vCores ist schon besser. Jetzt, wo du bei 12 bist, beobachte mal %RDY und vor allem guck dir auch an, was in der VM passiert. Ist die stark ausgelastet oder eher unterbeschäftigt? Vielleicht wird die Leistung auch einfach nicht genutzt und ob 8 oder 12 merkt der Anwender gar nicht, dann ist weniger definitiv mehr.
Auch, wie viele vCores es denn nun sein sollten, ist irgendwie Erfahrungsabhängig. Du sagst es gibt 48 pCores, leider aber nicht, wie sich die aufteilen. Ich denke, bis 8 vCores geht jeder mit. Ansonsten sicherlich nie mehr, als eine einzelne CPU im Blech hat, wegen NUMA & Co. Bei 48 pCores in einem 2 CPU System wären das also allerhöchstens 24. Das ist dann aber ein Wert den man machen kann wenn z.B. sonst nichts oder fast nichts auf dem Host los ist. Wenn es z.B. einen anderen RD-SH gibt mit der selben Konfiguration dann ist das natürlich auch viel zu viel. Alles, was an VMs durchgehend rechnen muss, sollte irgendwo auch alle seine vCores gleichzeitig bekommen können.
Und Verteilung auf mehrere RD-SH mit weniger vCores ist schon besser. Jetzt, wo du bei 12 bist, beobachte mal %RDY und vor allem guck dir auch an, was in der VM passiert. Ist die stark ausgelastet oder eher unterbeschäftigt? Vielleicht wird die Leistung auch einfach nicht genutzt und ob 8 oder 12 merkt der Anwender gar nicht, dann ist weniger definitiv mehr.
