177
Hyper V Server 2019, Gast Server 2016, Intel X722, langsame ext. Netzwerkanbindung
Hallo Community,
ich habe hier ein Problem mit extrem langsamen Netzwerkanbindungen von mehreren VM. Hardware sind zwei fast identische neue Maschinen (MB Supermicro X11SPM-F mit 2x 1 GB Intel X722 onBoard NIC und sep. IPMI, Intel Xeon Silver 4110, 96 GB RAM, lokales SSD Storage, soweit schön) auf denen je Windows Server 2019 Std. mit aktivierter Hyper V Rolle als Host installiert ist. Treiber sind erstmal alle original vom Hersteller was Supermicro halt so bereit stellt (Intel MB Chipsatz, Intel Pro 23.2 u.a.). Die Maschinen haben eine sep. IPMI NIC, die erste X722 NIC von dem Server verwende ich für das Hyper V Verwaltungsinterface, die zweite als HV Switch für die ext. Anbindung aller VM. Wenn ich Windows Server 2019 Std. in einer VM installiere ist alles gut, alles läuft wie es laufen soll. Wenn ich Windows Server 2016 Std. oder Server 2008R2 Std. in einer VM auf dem Host installiere haben diese VM nur je eine sehr sehr langsame Anbindung an die Aussenwelt. Ich hab das alles mal mit iperf getestet. Zwischen den VM ist die Transferrate wie gewünscht (iperf. knapp 10 GBit/s), von den VM zum Host auch (da das extern über einen Switch geht nur rd. 1 GBit/s, wenn ich einen HV Switch an das Verwaltungsinterface binde dann auch schneller), zu physischen Computern nach aussen hin im realen Netzwerk komme ich bei der einen Maschine aber nur auf 5-10 MBit/s und bei der anderen auf 20-120 MBit/s mit stark schwankender Tendenz - je nachdem. Der verwendete HW Switch ist entweder mal ein D-Link DGS 1210-28 oder ein HP 2510G-24, blank und nahezu unkonfiguriert, was halt grad so rumliegt. Mir geht ein klein wenig die Zeit aus weil beide Maschinen produktiv gehen sollen. Die erste steht schon vor Ort und dort ist mir das erst aufgefallen als ich von einem vorh. Server Daten migrieren wollte, das dauert ewig. Die andere noch bei mir im Labor und mit der habe ich nun schon einiges probiert: mehrfach Windows Server 2019 und 2016 auf dem Host installiert (meist wirklich neu von null an), div. VM installiert (Gen 1 und Gen 2), div. Intel Netzwerkkartentreiberversionen für die X722 installiert (23.0, 23.2, 23.4, aktuell 23.5), deren physische Zuordnungen hin und her geändert und auch an deren Parametern rumgespielt (Stichworte Flusssteuerung, VMQ, Lange send Offload v2 u.a. auf dem Host und in den VM), Hyper V Rolle deaktiviert und aktiviert. Ich habe die letzten Tage schon einige umfangreiche Installationsorgien hinter mir um das Problem einzukreisen - insbes. da das ändern der Intel NIC Treiber immer mit dem Löschen des HV Switches und Neustart des Hosts verbunden ist. Nur das BIOS des MB habe ich derzeit noch in Ruhe gelassen da dort meiner Meinung nach nichts für dieses Problem relevante einzustellen ist. Dabei kommt u.a. auf dem 2019 Host immer mal wieder das Problem auf dass ich keinen virt. Switch mit ext. Anbindung erstellen kann (Stichwort Hyper V Rolle deinstallieren, netcfg -d, Neustart, Hyper V Rolle aktivieren, alles neu einrichten ...) - aber das nur am Rande.
Letztendlich hat das alles mehr oder weniger nichts gebracht. Derzeitiges Fazit: sobald auf dem Host ein Server 2019 als Hyper V läuft auf dem in einer VM kein Server 2019 läuft (habe es mit Server 2016 und 2008R2 probiert) dann ist die Netzwerkanbindung dieser VM nach aussen über die Intel X722 extrem langsam. CPU Leistung steigt nicht, keine Fehlerpakete am Hardware Switch, es kommt halt einfach zu wenig an. Ich weiss auch spontan nicht wonach ich weiter suchen sollte und wo da der Flaschenhals ist (Paketgrößen?, Jumbo Pakete sind aber überall deaktiviert). Läuft auf dem Host Server 2016 als Hyper V funktioniert alles wie gewünscht. Das Problem habe ich z.Z. temporär gelöst indem ich eine weitere separate physische PCIe NIC (eine einfache Intel i210) eingebaut habe, an diese einen eigenen HV Switch gebunden und alle VM über diesen laufen lasse. Sobald ich die 2016er VM über einen HV Switch wieder über die onBoard NIC Intel X722 nach aussen anbinde haben externe PC die o.g. schlechte Netzwerkanbindung. Mit dem HV Switch der i210 geht das schnell wie gewünscht.
Meine Fragen: kennt jemand dieses Problem in dieser Konstellation (HV 2019, Intel NIC X722, HV Gast 2016)? Gibt es eine Lösung oder hat jemand weitere Ansätze zur Suche?
ich habe hier ein Problem mit extrem langsamen Netzwerkanbindungen von mehreren VM. Hardware sind zwei fast identische neue Maschinen (MB Supermicro X11SPM-F mit 2x 1 GB Intel X722 onBoard NIC und sep. IPMI, Intel Xeon Silver 4110, 96 GB RAM, lokales SSD Storage, soweit schön) auf denen je Windows Server 2019 Std. mit aktivierter Hyper V Rolle als Host installiert ist. Treiber sind erstmal alle original vom Hersteller was Supermicro halt so bereit stellt (Intel MB Chipsatz, Intel Pro 23.2 u.a.). Die Maschinen haben eine sep. IPMI NIC, die erste X722 NIC von dem Server verwende ich für das Hyper V Verwaltungsinterface, die zweite als HV Switch für die ext. Anbindung aller VM. Wenn ich Windows Server 2019 Std. in einer VM installiere ist alles gut, alles läuft wie es laufen soll. Wenn ich Windows Server 2016 Std. oder Server 2008R2 Std. in einer VM auf dem Host installiere haben diese VM nur je eine sehr sehr langsame Anbindung an die Aussenwelt. Ich hab das alles mal mit iperf getestet. Zwischen den VM ist die Transferrate wie gewünscht (iperf. knapp 10 GBit/s), von den VM zum Host auch (da das extern über einen Switch geht nur rd. 1 GBit/s, wenn ich einen HV Switch an das Verwaltungsinterface binde dann auch schneller), zu physischen Computern nach aussen hin im realen Netzwerk komme ich bei der einen Maschine aber nur auf 5-10 MBit/s und bei der anderen auf 20-120 MBit/s mit stark schwankender Tendenz - je nachdem. Der verwendete HW Switch ist entweder mal ein D-Link DGS 1210-28 oder ein HP 2510G-24, blank und nahezu unkonfiguriert, was halt grad so rumliegt. Mir geht ein klein wenig die Zeit aus weil beide Maschinen produktiv gehen sollen. Die erste steht schon vor Ort und dort ist mir das erst aufgefallen als ich von einem vorh. Server Daten migrieren wollte, das dauert ewig. Die andere noch bei mir im Labor und mit der habe ich nun schon einiges probiert: mehrfach Windows Server 2019 und 2016 auf dem Host installiert (meist wirklich neu von null an), div. VM installiert (Gen 1 und Gen 2), div. Intel Netzwerkkartentreiberversionen für die X722 installiert (23.0, 23.2, 23.4, aktuell 23.5), deren physische Zuordnungen hin und her geändert und auch an deren Parametern rumgespielt (Stichworte Flusssteuerung, VMQ, Lange send Offload v2 u.a. auf dem Host und in den VM), Hyper V Rolle deaktiviert und aktiviert. Ich habe die letzten Tage schon einige umfangreiche Installationsorgien hinter mir um das Problem einzukreisen - insbes. da das ändern der Intel NIC Treiber immer mit dem Löschen des HV Switches und Neustart des Hosts verbunden ist. Nur das BIOS des MB habe ich derzeit noch in Ruhe gelassen da dort meiner Meinung nach nichts für dieses Problem relevante einzustellen ist. Dabei kommt u.a. auf dem 2019 Host immer mal wieder das Problem auf dass ich keinen virt. Switch mit ext. Anbindung erstellen kann (Stichwort Hyper V Rolle deinstallieren, netcfg -d, Neustart, Hyper V Rolle aktivieren, alles neu einrichten ...) - aber das nur am Rande.
Letztendlich hat das alles mehr oder weniger nichts gebracht. Derzeitiges Fazit: sobald auf dem Host ein Server 2019 als Hyper V läuft auf dem in einer VM kein Server 2019 läuft (habe es mit Server 2016 und 2008R2 probiert) dann ist die Netzwerkanbindung dieser VM nach aussen über die Intel X722 extrem langsam. CPU Leistung steigt nicht, keine Fehlerpakete am Hardware Switch, es kommt halt einfach zu wenig an. Ich weiss auch spontan nicht wonach ich weiter suchen sollte und wo da der Flaschenhals ist (Paketgrößen?, Jumbo Pakete sind aber überall deaktiviert). Läuft auf dem Host Server 2016 als Hyper V funktioniert alles wie gewünscht. Das Problem habe ich z.Z. temporär gelöst indem ich eine weitere separate physische PCIe NIC (eine einfache Intel i210) eingebaut habe, an diese einen eigenen HV Switch gebunden und alle VM über diesen laufen lasse. Sobald ich die 2016er VM über einen HV Switch wieder über die onBoard NIC Intel X722 nach aussen anbinde haben externe PC die o.g. schlechte Netzwerkanbindung. Mit dem HV Switch der i210 geht das schnell wie gewünscht.
Meine Fragen: kennt jemand dieses Problem in dieser Konstellation (HV 2019, Intel NIC X722, HV Gast 2016)? Gibt es eine Lösung oder hat jemand weitere Ansätze zur Suche?
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: 396761
Url: https://administrator.de/contentid/396761
Ausgedruckt am: 21.11.2024 um 19:11 Uhr
177 Kommentare
Neuester Kommentar
Hallo,
Firmware aktuell?
Systeme auf aktuellem systemstand?
Was sagt der Hersteller? (Gut über Weihnachten ist das natürlich problematisch)
Was ergibt eine Googlesuche?
Ereignisanzeige?
VG
Firmware aktuell?
Systeme auf aktuellem systemstand?
Was sagt der Hersteller? (Gut über Weihnachten ist das natürlich problematisch)
Was ergibt eine Googlesuche?
Ereignisanzeige?
VG
Moin,
da du schon vieles versucht hast, würde ich mich hier direkt an den Hersteller oder den Lieferanten wenden.
Da diese Server anscheinend neu und für den produktiven Einsatz vorgesehen sind, gehe ich davon aus, dass du diese unter einem Wartungsvertrag hast. Wie lange ist dort die Reaktionszeit?
Gruß
maxblank
da du schon vieles versucht hast, würde ich mich hier direkt an den Hersteller oder den Lieferanten wenden.
Da diese Server anscheinend neu und für den produktiven Einsatz vorgesehen sind, gehe ich davon aus, dass du diese unter einem Wartungsvertrag hast. Wie lange ist dort die Reaktionszeit?
Gruß
maxblank
Firmware ist an allen Teilen aktuell. Systeme auch. Ich vermute es ist ein Treiber- oder Einstellungsproblem irgendwo. Wir assemblieren selber, d.h. sind selber der Hersteller - sind eh nur kleine Systeme aus Standardkomponenten welche lt. Herstellerangaben dafür und in dieser Konstellation vorgesehen sind.
Google 2 Tage gesucht: bis auf VMQ nichts gefunden was annähernd dem Problem entspricht. Auf jeden Fall nichst spezifisches zum Problem HV 2019 Gast 2016 oder 2008R2 (2012R2 wäre sicher ebenso betroffen, könnte ich testen, fehlt mir grad die Zeit).
Ereignisanzeige sieht total schick aus - nix.
Problem ist derzeit exakt diese Kombination: X722 + HV 2019 + Gast 2016. Andere NIC, anderer Host, 2019 als Gast dann geht es.
Google 2 Tage gesucht: bis auf VMQ nichts gefunden was annähernd dem Problem entspricht. Auf jeden Fall nichst spezifisches zum Problem HV 2019 Gast 2016 oder 2008R2 (2012R2 wäre sicher ebenso betroffen, könnte ich testen, fehlt mir grad die Zeit).
Ereignisanzeige sieht total schick aus - nix.
Problem ist derzeit exakt diese Kombination: X722 + HV 2019 + Gast 2016. Andere NIC, anderer Host, 2019 als Gast dann geht es.
Dann solltest du dich an den mobo Hersteller wenden. Sehe soweit kein Problem auf den Konstellationen (dell basiert)
Hat dein Dell Server die gleiche NIC? Woanders (andere onBoard NIC) habe ich das Problem ja auch nicht.
Hmm.
Hier steht das Teil [X11SPM-F] hätte zwei 1GbE Marvel Controller, keine Intel.
https://www.supermicro.com/products/motherboard/Xeon/C620/X11SPM-F.cfm
Dual LAN with 1GbE with Marvell® 88E1512
Gruß A.
Btw. Server 2019 produktiv nutzen? Da würde ich das Ding erst mal noch mind. ein Jahr reifen lassen bis zumindest die gröbsten Schnitzer behoben sind, denn davon gibt es nach meiner Evaluation der letzten Build noch einige.
Hier steht das Teil [X11SPM-F] hätte zwei 1GbE Marvel Controller, keine Intel.
https://www.supermicro.com/products/motherboard/Xeon/C620/X11SPM-F.cfm
Dual LAN with 1GbE with Marvell® 88E1512
Gruß A.
Btw. Server 2019 produktiv nutzen? Da würde ich das Ding erst mal noch mind. ein Jahr reifen lassen bis zumindest die gröbsten Schnitzer behoben sind, denn davon gibt es nach meiner Evaluation der letzten Build noch einige.
Moin...
jo, der 2019er ist sehr buggy... lass das beser mal.
nutze deinen server richtig, mache es mit ESXI 6.5... die 6.7er würde ich noch nicht nehmen wollen!
Frank
jo, der 2019er ist sehr buggy... lass das beser mal.
nutze deinen server richtig, mache es mit ESXI 6.5... die 6.7er würde ich noch nicht nehmen wollen!
Frank
Sind Intel NIC:
Ich weiss nicht wieso das auf der Supermicro Site und auch im Handbuch so steht (vielleicht ist nur der physische Endteil Marvell? kann grad kein Bild machen weil ncht mehr vor Ort), aber die Treiber Downloads und auch die OUI Herstellerkennung sind da recht eindeutig ;)
Hyper V ist schon nicht schlecht, ist glaub mein vierter produktiver Einsatz seit div. Tests und der MS Freigabe (nicht nur als Hyper V). Aber so ein Problem allein schon beim Hyper V finde ich nicht lustig.
Ich weiss nicht wieso das auf der Supermicro Site und auch im Handbuch so steht (vielleicht ist nur der physische Endteil Marvell? kann grad kein Bild machen weil ncht mehr vor Ort), aber die Treiber Downloads und auch die OUI Herstellerkennung sind da recht eindeutig ;)
Hyper V ist schon nicht schlecht, ist glaub mein vierter produktiver Einsatz seit div. Tests und der MS Freigabe (nicht nur als Hyper V). Aber so ein Problem allein schon beim Hyper V finde ich nicht lustig.
OK, da hat Supermicro tatsächlich etwas in der Doku geschlampt, siehe
https://vmware-forum.de/viewtopic.php?t=32808
Das OS reift beim Kunden, nicht anders wie bei den Client OS.. Deswegen bei Virtualisierung besser gleich zur Bewährtem greifen.
https://vmware-forum.de/viewtopic.php?t=32808
Aber so ein Problem allein schon beim Hyper V finde ich nicht lustig.
Gerade bei der Hyper-V Rolle machen sich die meisten Unzulänglichkeiten beim 2019er bemerkbar.Das OS reift beim Kunden, nicht anders wie bei den Client OS.. Deswegen bei Virtualisierung besser gleich zur Bewährtem greifen.
Zitat von @137846:
OK, da hat Supermicro tatsächlich etwas in der Doku geschlampt, siehe
https://vmware-forum.de/viewtopic.php?t=32808
Das OS reift beim Kunden, nicht anders wie bei den Client OS..
OK, da hat Supermicro tatsächlich etwas in der Doku geschlampt, siehe
https://vmware-forum.de/viewtopic.php?t=32808
Aber so ein Problem allein schon beim Hyper V finde ich nicht lustig.
Gerade bei der Hyper-V Rolle machen sich die meisten Unzulänglichkeiten beim 2019er bemerkbar.Das OS reift beim Kunden, nicht anders wie bei den Client OS..
Findest du? Seit dem letzten Update läuft das auf meinen Testsystemen sehr gut. Mittlerweile 5 Systeme 24/7 aktiv.
Welche Probleme siehst du da?
Aber: Anscheinend wird von VMware 6.7 auch (noch) abgeraten ;) also nicht besser.
Ähnliche Probleme schien es schon mit den alten Treiberversionen gegeben haben in Verbindung mit dem 2019er. Scheinbar funktioniert dann der 23.5er auch nicht richtig mit 2019 trotz Freigabe für die 1809 von Intel.
Hier hilft nur Kontakt mit Intel aufnehmen und ggf. Microsoft.
Hier hilft nur Kontakt mit Intel aufnehmen und ggf. Microsoft.
So ähnlich habe ich das inzwischen auch aus den Errata bei Intel rausgelesen. Es waren Probleme in dieser Richtung bekannt, die 23.5 sollte diese beheben, tut sie aber nicht.
Der Vollständigkeit halber:
Es sind Marvell Phy Transceiver für die Konnektoren. Die NIC sind intern und Intel.
Der Vollständigkeit halber:
Es sind Marvell Phy Transceiver für die Konnektoren. Die NIC sind intern und Intel.
kurz zusammengefaßt einer der 30 Parameter der Netzwerkkarte (die Detaileinstellungen im Gerätemanager) im Gast paßt wohl nicht zu den physischen Fähigkeiten des Intel NIC X722
2016 hat nen Bug der in 2019 vielleicht auch drin ist - es aktiviert einige Features an der Netzwerkkarte wie z.B. das RSS oder noch ein paar weitere "Offloading" Optionen, die auf physischen Karten dann Teile des TCP-IP Protokolls in Hardware umsetzen wie z.B. Checksum Prüfungen oder Hashberechnungen. Ich hatte gerad nen Kunden am Rohr, der auf 2016 Terminalserver eine Roundtrip Latency von sage und schreibe 2000 ms hatte, dabei waren Client und Server keine 2 km voneinander entfernt. Bei 2008R2 lag er bei 17 ms.
ICh hatte neulich auch mal ein 2016 auf ESX installiert, und mit Defaulteinstellungen war das Netz langsam bis unbenutzbar, dann VMware Tools installiert aber nicht viel besser geworden... Unter 2012 R2 auf demselben Host gingen dann Downloads bei MS so wusch mit Maximalbandbreite des CDN von Microsoft (ca. 120 Mbit) ... ich hab sogar die Ports getauscht konnte aber keinen finden der daran schuld war. Und stellt man aber auf 2012 R2 und dem E1000E Treiber das RSS ein, dann bricht der Download dramatisch ein und acuh die VMware Tools halfen zunächst nicht.... das ist aber in aktuellen VMware Tools dann gefixt.
2016 hat nen Bug der in 2019 vielleicht auch drin ist - es aktiviert einige Features an der Netzwerkkarte wie z.B. das RSS oder noch ein paar weitere "Offloading" Optionen, die auf physischen Karten dann Teile des TCP-IP Protokolls in Hardware umsetzen wie z.B. Checksum Prüfungen oder Hashberechnungen. Ich hatte gerad nen Kunden am Rohr, der auf 2016 Terminalserver eine Roundtrip Latency von sage und schreibe 2000 ms hatte, dabei waren Client und Server keine 2 km voneinander entfernt. Bei 2008R2 lag er bei 17 ms.
ICh hatte neulich auch mal ein 2016 auf ESX installiert, und mit Defaulteinstellungen war das Netz langsam bis unbenutzbar, dann VMware Tools installiert aber nicht viel besser geworden... Unter 2012 R2 auf demselben Host gingen dann Downloads bei MS so wusch mit Maximalbandbreite des CDN von Microsoft (ca. 120 Mbit) ... ich hab sogar die Ports getauscht konnte aber keinen finden der daran schuld war. Und stellt man aber auf 2012 R2 und dem E1000E Treiber das RSS ein, dann bricht der Download dramatisch ein und acuh die VMware Tools halfen zunächst nicht.... das ist aber in aktuellen VMware Tools dann gefixt.
Meine stille Hoffnung ist immer noch dass es ein solcher Fehler ist der sich durch entspr. Einstellungen beheben lässt, so auch meine ursprüngliche Frage: kennt das jemand.
Auf dem (neu installierten) Host habe ich nur noch die 23.5 Intel Treiber und kein Pro Set mehr installiert. Im Gerätemanager habe ich bei den Karten die Flusssteuerung, IPv4 Prüfsummen Abladung, Large-Send-Offload v2 (IPv4 und v6), NS-Abladung, TCP-Prüfsummen abladen (IPv4 und v6) und UDP-Prüfsummen abladen (IPv4 und v6) deaktiviert. Per Registry auch mal VMQ explizit deaktiviert. Soweit möglich das auch in den VM NIC Einstellungen eingestellt. Das alles immer Stückweise mit zwischenzeitlichem testen und tlw. Neustarts. RSS Einstellungen habe ich belassen, wenn überhaupt dann könnte man die vergrößern für mehr Last. An weiteren Parametern habe ich hier und da probiert (u.a. Recv.-Segment-Coalescing IPv4 und v6). Fazit - hat alles nichts gebracht. Ich habe keinen kleinsten gemeinsamen Nenner gefunden bei dem ich auf mehr Geschwindigkeit komme. Da gibt es aber eben immer noch einige Einstellungen und Kombinationen die ich sicher nicht getestet habe und ein Teil der Einstellungen lässt sich nur per Registry anpassen. Das wurde mir dann zu viel und der Hickhack zu groß. Eine beliebte Einstellung früher war halt Flusssteuerung, Prüfsummenabladung und Large-Send-Offload v2 - aber das hat's hier auch nicht gebracht. Ebenso Interrupt Drosselung usw. . Die CPU und IRQ dümpeln dennoch rum und das Netz ist nach extern langsam. Das alles war bisher keine Lösung bei mir.
Auf dem (neu installierten) Host habe ich nur noch die 23.5 Intel Treiber und kein Pro Set mehr installiert. Im Gerätemanager habe ich bei den Karten die Flusssteuerung, IPv4 Prüfsummen Abladung, Large-Send-Offload v2 (IPv4 und v6), NS-Abladung, TCP-Prüfsummen abladen (IPv4 und v6) und UDP-Prüfsummen abladen (IPv4 und v6) deaktiviert. Per Registry auch mal VMQ explizit deaktiviert. Soweit möglich das auch in den VM NIC Einstellungen eingestellt. Das alles immer Stückweise mit zwischenzeitlichem testen und tlw. Neustarts. RSS Einstellungen habe ich belassen, wenn überhaupt dann könnte man die vergrößern für mehr Last. An weiteren Parametern habe ich hier und da probiert (u.a. Recv.-Segment-Coalescing IPv4 und v6). Fazit - hat alles nichts gebracht. Ich habe keinen kleinsten gemeinsamen Nenner gefunden bei dem ich auf mehr Geschwindigkeit komme. Da gibt es aber eben immer noch einige Einstellungen und Kombinationen die ich sicher nicht getestet habe und ein Teil der Einstellungen lässt sich nur per Registry anpassen. Das wurde mir dann zu viel und der Hickhack zu groß. Eine beliebte Einstellung früher war halt Flusssteuerung, Prüfsummenabladung und Large-Send-Offload v2 - aber das hat's hier auch nicht gebracht. Ebenso Interrupt Drosselung usw. . Die CPU und IRQ dümpeln dennoch rum und das Netz ist nach extern langsam. Das alles war bisher keine Lösung bei mir.
Ich bekomme morgen eine X722 in die Finger, dann mach ich hier auch mal ein paar Tests um das nachzustellen.
Gruß A.
Gruß A.
Also, ich habe das ganze hier mal mit einem SM Board mit X722 NIC nachgestellt (hatten wir hier noch auf Ersatz-Lager liegen):
Also k.A. was da bei dir dazwischen funkt und du beim Aufsetzen anders machst.
Gruß A.
- Server 2019 Datacenter mit allen verfügbaren Updates (nur Hyper-V als Rolle)
- Gast jeweils mit fest zugewiesenen 4GB RAM und 2 vCPUs
- Sowohl beim Gast mit Server 2016 Datacenter (alle Updates), als auch Server 2008R2 (mit allen Updates) laufen die NICs sehr nah am theroetischen Max. durchschn. 950MBit/s (netio) über einen CISCO SG350-52 Switch auf einen Windows 10 1809 Client mit 1GB Intel-NIC. VM Gen 1. oder 2. machten dabei keinen Unterschied.
- Treiber von Intel ist der letzte verfügbare 23.5, Anpassungen an den NICs sowohl am Hosts als auch am Gast waren nicht nötig.
Also k.A. was da bei dir dazwischen funkt und du beim Aufsetzen anders machst.
Gruß A.
Danke, schön zu wissen dass es auch anders geht. Hilft mir halt nicht weiter. Ich hab das von MS freigegebene 2019er ISO SW_DVD9_Win_Server_STD_CORE_2019_64Bit_German_DC_STD_MLF_X21-96583.ISO aus dem MS Partner Portal genommen. Mehrfach von Null an neu installiert, zuletzt nahezu nichts mehr auf dem Host und in den VM eingerichtet. Problem war reproduzierbar immer wieder da.
Und genau an dem Punkt (oder ggf davor) hilft ein Forum wohl nicht mehr weiter.
Es hat mir geholfen - zumindest in der Beziehung dass andere das Problem so nicht haben. Es ist wie immer: suche den Fehler bei dir selbst, hilf dir selbst.
hilf dir selbst.
Und ab und zu auch anderen 
.Darf man das zurück geben, wie gesagt, genau an dem Punkt - hilf dir selbst.
Moin...
Updates ?
allerdings finde ich dein Unterfangen, einen Hyper-V auf basis des 2019er nutzen zu wollen, doch sehr gewagt... ich traue dem braten nicht....
Mehrfach von Null an neu installiert, zuletzt nahezu nichts mehr auf dem Host und in den VM eingerichtet. Problem war reproduzierbar immer wieder da.
hast du auch die VM´s neu installiert?
Frank
Zitat von @bonbastler:
Danke, schön zu wissen dass es auch anders geht. Hilft mir halt nicht weiter. Ich hab das von MS freigegebene 2019er ISO SW_DVD9_Win_Server_STD_CORE_2019_64Bit_German_DC_STD_MLF_X21-96583.ISO aus dem MS Partner Portal genommen.
und welche Build version hast du nach der Installation genau....Danke, schön zu wissen dass es auch anders geht. Hilft mir halt nicht weiter. Ich hab das von MS freigegebene 2019er ISO SW_DVD9_Win_Server_STD_CORE_2019_64Bit_German_DC_STD_MLF_X21-96583.ISO aus dem MS Partner Portal genommen.
Updates ?
allerdings finde ich dein Unterfangen, einen Hyper-V auf basis des 2019er nutzen zu wollen, doch sehr gewagt... ich traue dem braten nicht....
Mehrfach von Null an neu installiert, zuletzt nahezu nichts mehr auf dem Host und in den VM eingerichtet. Problem war reproduzierbar immer wieder da.
hast du auch die VM´s neu installiert?
Frank
Die 2019 waren und sind immer die 1809 Build 17763.195.
Ja, auch die VM wurden oft neu installiert, aber ich gebe zu: nur bei jeder 2. Neuinstallation des Host, abhängig von den Spielereien die ich an den NIC in den VM durchgeführt habe.
Das ist selbstverständlich. Ich gebe wenn ich kann immer zurück. Vor allem dann wenn ich wirklich mal irgendwo frage und - wie so oft - keine Lösung kurzfristig gefunden wird dann schreibe ich zumindest wenn ich eine finde diese nachträglich noch dazu. Falls andere vor dem Problem stehen hilft das denen - ist die Hoffnung.
Ja, auch die VM wurden oft neu installiert, aber ich gebe zu: nur bei jeder 2. Neuinstallation des Host, abhängig von den Spielereien die ich an den NIC in den VM durchgeführt habe.
Das ist selbstverständlich. Ich gebe wenn ich kann immer zurück. Vor allem dann wenn ich wirklich mal irgendwo frage und - wie so oft - keine Lösung kurzfristig gefunden wird dann schreibe ich zumindest wenn ich eine finde diese nachträglich noch dazu. Falls andere vor dem Problem stehen hilft das denen - ist die Hoffnung.
Moin...
hm...
warum solle es ein 2019er Hyper-V Host werden?
nutze doch den ESXI 6.5.... mach es besser gleich richtig!
Ja, auch die VM wurden oft neu installiert, aber ich gebe zu: nur bei jeder 2. Neuinstallation des Host, abhängig von den Spielereien die ich an den NIC in den VM durchgeführt habe.
na ja... das sollte schon mit den grundeinstellungen klappen....
hast du mal eine ander NIC in dein Blech geklemmt?
hast du den Server bestellt für 2019.. was sagt der Hersteller dazu? support?
Das ist selbstverständlich. Ich gebe wenn ich kann immer zurück. Vor allem dann wenn ich wirklich mal irgendwo frage und - wie so oft - keine Lösung kurzfristig gefunden wird dann schreibe ich zumindest wenn ich eine finde diese nachträglich noch dazu. Falls andere vor dem Problem stehen hilft das denen - ist die Hoffnung.
Frank
hm...
warum solle es ein 2019er Hyper-V Host werden?
nutze doch den ESXI 6.5.... mach es besser gleich richtig!
Ja, auch die VM wurden oft neu installiert, aber ich gebe zu: nur bei jeder 2. Neuinstallation des Host, abhängig von den Spielereien die ich an den NIC in den VM durchgeführt habe.
hast du mal eine ander NIC in dein Blech geklemmt?
hast du den Server bestellt für 2019.. was sagt der Hersteller dazu? support?
Das ist selbstverständlich. Ich gebe wenn ich kann immer zurück. Vor allem dann wenn ich wirklich mal irgendwo frage und - wie so oft - keine Lösung kurzfristig gefunden wird dann schreibe ich zumindest wenn ich eine finde diese nachträglich noch dazu. Falls andere vor dem Problem stehen hilft das denen - ist die Hoffnung.
Frank
Frank, an Server 2019 per SE liegt es nicht. S.o das Problem könnte auch an der Konfektion liegen. Der wird selbst durch den to zusammen geschraubt.
VG
VG
So klein sind wir nun nicht. Assemblieren ist kein Hexenwerk. Wir können dieses Blech exakt so auch von einem der Großen bauen lassen, das sind Standardkomponenten, die sind auch bei denen in dieser Kombination zertifiziert (weiss ich), das wird dann halt ein BTO System - kein Problem. Dann bieten dieser Hersteller des BTO Systems den Support und ich würde tagelang und irgendwann auch kostenpflichtig mit denen telefonieren. Könnten wir machen. Ist grad nicht. Die beiden Systeme sind schon da.
Naja dann wurde ich mal sagen, entweder ihr schaut was ihr mit den Systemen macht oder ihr ordert bei den grossen ein entsprechendes system. Da du hier nun schon tagelang und zog Installationen durch hast dürfte es so langsam billiger sein sich nach einer alternative um zuschauen.
Vielleicht geht es momentan einfach nicht aufgrund eines anderen problems, dass gerade gar nicht mit der nicht zusammenhängt, aber die Leistung frisst.
Vielleicht geht es momentan einfach nicht aufgrund eines anderen problems, dass gerade gar nicht mit der nicht zusammenhängt, aber die Leistung frisst.
Spätestens für das zweite System was ich zu dem Zeitpunkt noch nicht ausgeliefert hatte kann ich das zum Großteil ausschließen.
Die pragmatische Lösung sieht aktuell so aus dass die Systeme je eine weitere NIC drin haben über welche die VM nach aussen kommunizieren.
Zusätzlich habe ich noch die problematisch funktionierenden onBoard NICs extern angebunden und kann so remote in Ruhe weiter nach Ursachen forschen wenn es die Zeit mal wieder hergibt - dank IPMI, ext. gelagerten Backups und Installationsmedien ist das möglich. Demnächst kommt noch so ein drittes System an und vielleicht lasse ich mir gar mal das Gleiche von anderen bauen um die dann mit dem evtl. noch auftretenden Problem zu nerven. Mal schauen was die Zeit so mit sich bringt. Wenn ich eine Ursache und praktikable Lösung finde kommt das hier rein.
Die pragmatische Lösung sieht aktuell so aus dass die Systeme je eine weitere NIC drin haben über welche die VM nach aussen kommunizieren.
Zusätzlich habe ich noch die problematisch funktionierenden onBoard NICs extern angebunden und kann so remote in Ruhe weiter nach Ursachen forschen wenn es die Zeit mal wieder hergibt - dank IPMI, ext. gelagerten Backups und Installationsmedien ist das möglich. Demnächst kommt noch so ein drittes System an und vielleicht lasse ich mir gar mal das Gleiche von anderen bauen um die dann mit dem evtl. noch auftretenden Problem zu nerven. Mal schauen was die Zeit so mit sich bringt. Wenn ich eine Ursache und praktikable Lösung finde kommt das hier rein.
Moin...
nun sag das mal nicht... wir machen das schon über 25 Jahre....
also doch ein problem....
natürlich kann jerder Hans und Franz einen Server zusammenschustern, darum geht es nicht- es geht darum zu wissen wie, mit was der Server rennt... und vor allem warum!
das wissen fehlt leider bei den meisten....
nutze in zukunft lieber das Server Board Intel S2600BPS...
witzig finde ich auch, das du bei der 2019er Hyper-V kiste bleiben willst, obwohl dir fast jeder davon abraten würde...
Frank
nun sag das mal nicht... wir machen das schon über 25 Jahre....
Wir können dieses Blech exakt so auch von einem der Großen bauen lassen, das sind Standardkomponenten, die sind auch bei denen in dieser Kombination zertifiziert (weiss ich), das wird dann halt ein BTO System - kein Problem.
und für was zertifiziert? Server 2019.. ESXI? mit welcher Firmware / Bios Version... mit welchen einstellungen?also doch ein problem....
natürlich kann jerder Hans und Franz einen Server zusammenschustern, darum geht es nicht- es geht darum zu wissen wie, mit was der Server rennt... und vor allem warum!
das wissen fehlt leider bei den meisten....
Dann bieten dieser Hersteller des BTO Systems den Support und ich würde tagelang und irgendwann auch kostenpflichtig mit denen telefonieren. Könnten wir machen. Ist grad nicht. Die beiden Systeme sind schon da.
tja.. etwas support wäre nicht schlecht... nutze in zukunft lieber das Server Board Intel S2600BPS...
witzig finde ich auch, das du bei der 2019er Hyper-V kiste bleiben willst, obwohl dir fast jeder davon abraten würde...
Frank
Nabend...
nun sag das mal nicht... wir machen das schon über 25 Jahre....
Wir auch.
also doch ein problem....
natürlich kann jerder Hans und Franz einen Server zusammenschustern, darum geht es nicht- es geht darum zu wissen wie, mit was der Server rennt... und vor allem warum!
das wissen fehlt leider bei den meisten....
Generell 2019 zertifiziert, die sind noch dabei. Firmware soweit ich seit heute weiss auch gleich. Das mit den Einstellungen wäre interessant. Der Abteilung welche die Hardware beim Hersteller zertifiziert war recht überrascht von dem Problem und stellen das gerade (tlw. erfolgreich) nach. Demnächst weiss ich da mehr. Soviel auch zum Thema Support. Wir reden noch mit anderen und können das auch.
nutze in zukunft lieber das Server Board Intel S2600BPS...
witzig finde ich auch, das du bei der 2019er Hyper-V kiste bleiben willst, obwohl dir fast jeder davon abraten würde...
Frank
Tja Frank, ich finde das nicht witzig, das gleitet ab. Das Fazit für mich: dein Beitrag war in keiner Weise hilfreich oder konstruktiv. Ich finde auch du ziehst das Niveau des Beitrages und mich hier runter. Mag sein dass du das öfters machst, ich brauche das nicht. Es geht um das Thema, nicht um die Personen. Deine Mainboard Empfehlung ist am Thema vorbei, Thema Formfaktor, das ist dir vielleicht entgangen. Solche Kommentare brauche ich und vmtl. auch andere in diesem Thread nicht. Weiter gehe ich nicht darauf ein. Du musst das auch nicht kommentieren.
Bei Answer möchte ich mich nochmal bedanken sich den Aufwand gegeben und kurzfristig negativ nachgestellt zu haben.
nun sag das mal nicht... wir machen das schon über 25 Jahre....
Wir können dieses Blech exakt so auch von einem der Großen bauen lassen, das sind Standardkomponenten, die sind auch bei denen in dieser Kombination zertifiziert (weiss ich), das wird dann halt ein BTO System - kein Problem.
und für was zertifiziert? Server 2019.. ESXI? mit welcher Firmware / Bios Version... mit welchen einstellungen?also doch ein problem....
natürlich kann jerder Hans und Franz einen Server zusammenschustern, darum geht es nicht- es geht darum zu wissen wie, mit was der Server rennt... und vor allem warum!
das wissen fehlt leider bei den meisten....
Dann bieten dieser Hersteller des BTO Systems den Support und ich würde tagelang und irgendwann auch kostenpflichtig mit denen telefonieren. Könnten wir machen. Ist grad nicht. Die beiden Systeme sind schon da.
tja.. etwas support wäre nicht schlecht... nutze in zukunft lieber das Server Board Intel S2600BPS...
witzig finde ich auch, das du bei der 2019er Hyper-V kiste bleiben willst, obwohl dir fast jeder davon abraten würde...
Frank
Bei Answer möchte ich mich nochmal bedanken sich den Aufwand gegeben und kurzfristig negativ nachgestellt zu haben.
moin..
du solltest aber schon wissen, das die Intel S2600 Serie euch für dein Formfaktor zu erwerben ist!
ich verstehe nicht, warum sich die "assemblierer" aufregen, wenn ihnen gesagt wird, das ist Bockmist, was du da machst...
was ist für dich am Intel S2600 MB so schlecht als Empfehlung? weil du dann den Supermicro Schrott auf halde liegen hast?
Frank
Generell 2019 zertifiziert, die sind noch dabei.
sagt ja schon alles....es könnte sein, oder vieleicht!du solltest aber schon wissen, das die Intel S2600 Serie euch für dein Formfaktor zu erwerben ist!
Tja Frank, ich finde das nicht witzig, das gleitet ab
das glaube ich dir gerne, den du verkaufst nicht supportete systeme, selbst für dein MB gibbet keine Server 2019 Treiber... aber gut, windows 10 ist ja schon mal ein anfang.ich verstehe nicht, warum sich die "assemblierer" aufregen, wenn ihnen gesagt wird, das ist Bockmist, was du da machst...
was ist für dich am Intel S2600 MB so schlecht als Empfehlung? weil du dann den Supermicro Schrott auf halde liegen hast?
Der Abteilung welche die Hardware beim Hersteller zertifiziert war recht überrascht von dem Problem und stellen....(tlw. erfolgreich) nach.
aha... dann sollte "Der Abteilung" dir besser mal vorschlagen, ein MB zu verbauen, was für deine zwecke auch 100% geeignet ist...Wir reden noch mit anderen und können das auch.
anscheinend nicht beim Bestellen....Frank
Frank, du kannst es nicht sein lassen, was? Ich hatte darum gebeten aber du musst unbedingt noch eins drauf setzen. Wie ich schon mal schrieb: das was du schreibst ist nicht mehr konstruktiv, das ist nicht hilfreif, trägt nicht zum Thema bei und wenn ich mir die ersten Posts anschaue und dann das was du schreibst und in welche Richtung du diesen Thread bewegst dann heisst das für mich du trollst hier rum. Hör doch bitte einfach auf. Das liest keiner mehr. Du lenkst vom Thema ab. Ich würde das so stehenlassen bis ich mehr über das Thema weiss.
LIeber bonbastler,
wenn du von uns nichts hören willst, dann musst du hier nicht verweilen und auch keine Kommentare oder Fragen abgeben. So Unrecht hat Frank mit seinen Statements nicht. Gut, bzgl. Vmware und Hyper-V da is' er halt einfach ein Kind von VMware, soll er sein, ist OK. Aber grundsätzlich hockst du(!) auf dem Problem, nicht wir. Wie immer gilt: Bist du mit dem Service im Forum nicht zufrieden, kaufe dir direkten Service (per Geldbetrag X) ein. Dem kannst du dann auch (bedingt) Vorschreiben, wie und was er zu melden hat.
Viele Grüße,
Christian
wenn du von uns nichts hören willst, dann musst du hier nicht verweilen und auch keine Kommentare oder Fragen abgeben. So Unrecht hat Frank mit seinen Statements nicht. Gut, bzgl. Vmware und Hyper-V da is' er halt einfach ein Kind von VMware, soll er sein, ist OK. Aber grundsätzlich hockst du(!) auf dem Problem, nicht wir. Wie immer gilt: Bist du mit dem Service im Forum nicht zufrieden, kaufe dir direkten Service (per Geldbetrag X) ein. Dem kannst du dann auch (bedingt) Vorschreiben, wie und was er zu melden hat.
Viele Grüße,
Christian
Hallo zusammen,
gibt es hier mittlerweile eine Lösung?
Wir stehen aktuell vor exakt dem gleichen Problem, jedoch in einer Server 2016-Umgebung (Supermicro X11-Board mit 2x Intel X722 10G SFP+).
Ich freue mich auf eine (kostruktive!) Rückmeldung.
Grüße, Stephan
gibt es hier mittlerweile eine Lösung?
Wir stehen aktuell vor exakt dem gleichen Problem, jedoch in einer Server 2016-Umgebung (Supermicro X11-Board mit 2x Intel X722 10G SFP+).
Ich freue mich auf eine (kostruktive!) Rückmeldung.
Grüße, Stephan
Hallo Stephan,
nein, offensichtlich nicht, oder der TO hat sich ohne Lösungsmitteilung verabschiedet - dann kommt diese i.d.R auch nicht mehr. Ist leider das um sich greifende"Hilfe abgreifen, aber nichts zum Forum beitragen".
VG
nein, offensichtlich nicht, oder der TO hat sich ohne Lösungsmitteilung verabschiedet - dann kommt diese i.d.R auch nicht mehr. Ist leider das um sich greifende"Hilfe abgreifen, aber nichts zum Forum beitragen".
VG
Certified: dem ist nicht so, zumindest nicht bei mir und nicht hier. Ich kann deine negative Einstellung diesbzgl. verstehen aber indem du einer möglichen Antwort vorgreifst wird hier wohl keine mehr kommen, nicht von mir, nicht hier, nicht nach so einer fruchtlosen Diskussion - s.o., du weisst - am Thema vorbei.
Ich hatte den Thread als gelöst markiert weil ich mir mit gewissem Aufwand mehrere Lösungen für das Problem erarbeitet habe. Ich werde die dem Frager direkt mitteilen dann wird das hier nicht wieder breitgetreten und zerredet. Ich finde das ist in zielführender.
mbplg19: du bekommst heute noch Post, ich brauche ein klein wenig Zeit zum Antworten.
Ich hatte den Thread als gelöst markiert weil ich mir mit gewissem Aufwand mehrere Lösungen für das Problem erarbeitet habe. Ich werde die dem Frager direkt mitteilen dann wird das hier nicht wieder breitgetreten und zerredet. Ich finde das ist in zielführender.
mbplg19: du bekommst heute noch Post, ich brauche ein klein wenig Zeit zum Antworten.
Hallo Bonbastler,
wenn du wirklich eine Lösung (oder gar mehrere) hast, dann pack diese hier ins Forum, denn auch wenn man die Lösung nun selbst erarbeitet hat, gehört das zum guten Ton, diese zu publizieren. Anders sieht es ggf. nur aus, wenn man dritte dafür bezahlt hat eine Lösung zu erarbeiten, das negierst du aber indirekt.
Viele Grüße.
PS: Bitte certifiedit.net
wenn du wirklich eine Lösung (oder gar mehrere) hast, dann pack diese hier ins Forum, denn auch wenn man die Lösung nun selbst erarbeitet hat, gehört das zum guten Ton, diese zu publizieren. Anders sieht es ggf. nur aus, wenn man dritte dafür bezahlt hat eine Lösung zu erarbeiten, das negierst du aber indirekt.
Viele Grüße.
PS: Bitte certifiedit.net
Ich werde das mit dem Frager zusammen abarbeiten und wenn sich eine repoduzierbare Lösung für andere ergibt werden wir die ggf. hier publizieren.
Hallo bonbastler
Habe ähnliche Probleme, biiiitte um eine Lösung.
Produktivserver beim Kunden sehr langsam.
Vielen Dank
Habe ähnliche Probleme, biiiitte um eine Lösung.
Produktivserver beim Kunden sehr langsam.
Vielen Dank
Hallo manuelm2,
was für ein Mainboard und was für Betriebssysteme (Hyper V Host und Gast)? Ausserdem: was genau meinst du mit 'sehr langsam'?
was für ein Mainboard und was für Betriebssysteme (Hyper V Host und Gast)? Ausserdem: was genau meinst du mit 'sehr langsam'?
Hallo bonbastler
Besten Dank für deine Antwort.
Mainboard ist X10SRH-CF mit Intel i350 Dual NIC, Host und VM sind mit Windows Server 2019 installiert.
Netzwerk von VM aus max. 34MBit!
Bereits gemacht, Switch, Kabel, Treiber, MS Updates, neue VM zum testen inst., etc.
Besten Dank für deine Antwort.
Mainboard ist X10SRH-CF mit Intel i350 Dual NIC, Host und VM sind mit Windows Server 2019 installiert.
Netzwerk von VM aus max. 34MBit!
Bereits gemacht, Switch, Kabel, Treiber, MS Updates, neue VM zum testen inst., etc.
Das ist gänzlich andere Hardware, die Vorgängerversion sozusagen. Mit diesen NIC habe ich noch nirgends Probleme.
Dann die Frage: hast du dir den gesamten Thread - insbes. die von mir durchgeführten Dinge der Eigenschaften der Netzwerkkarten - durchgelesen, hoffentlich verstanden (ist tlw. etwas spärlich geschildert) und auch bei dir angewandt? Inzwischen gibt es neuere Treiber von Intel auch für diese Karten die im Prinzip so ein Problem tangieren, ist die 23.5.2 (Treiber Intel), dort insbes. auch mal die readme durcharbeiten.
Dann die Frage: hast du dir den gesamten Thread - insbes. die von mir durchgeführten Dinge der Eigenschaften der Netzwerkkarten - durchgelesen, hoffentlich verstanden (ist tlw. etwas spärlich geschildert) und auch bei dir angewandt? Inzwischen gibt es neuere Treiber von Intel auch für diese Karten die im Prinzip so ein Problem tangieren, ist die 23.5.2 (Treiber Intel), dort insbes. auch mal die readme durcharbeiten.
Neuste Treiber habe ich installiert (23.5.2) keine Änderung.
Habe Testhalber SMB2/3 deaktiviert und via SMB1 laufen lassen, viel besser, zwischen 200MBit und 500MBit, schwankt sehr.
Ist aber keine Lösung, ich vermute es liegt an Windows Server 2019.
Habe Testhalber SMB2/3 deaktiviert und via SMB1 laufen lassen, viel besser, zwischen 200MBit und 500MBit, schwankt sehr.
Ist aber keine Lösung, ich vermute es liegt an Windows Server 2019.
Ich hatte das immer mit iperf getestet weil das Problem schon tiefer lag wie SMB. Würde ich dir auch empfehlen weiter unten anzusetzen und zu klären ob die Probleme auch dort auftreten. SMB ist dann schon wieder eine andere Geschichte.
Ich nehme an du hast bei dem Hyper V Server eine separate NIC ausschließlich für den Hyper V zur Verwaltung und das ist auch eine der 350er Intel NIC. Wie verhält es sich mit der, auch diese Probleme? Der erste Punkt ist doch: gibt es wesentliche Unterschiede in den Übertragungsraten zwischen ext. Maschinen und dem Hyper V (über einen ext. Switch), ext. Maschinen und den HV Gästen (über einen ext. Switch) und zwischen dem Hyper V und seinen Gästen (einmal über ext. Switch und einmal intern wenn die HV Verwaltung auf der NIC eines HV Switches aktiviert wurde) und das halt alles mal auf einer niedrigeren Ebene gemessen, iperf bietet sich da an.
Abschließende Frage: ist irgendwo Teaming oder ein sonstige NIC Gruppierung aktiv oder war es mal?
Wie ich dir schon schrieb: einfach nur die Treiber zu installieren nutzt u.U. nicht. In der readme zu den Treibern stehen einige wesentliche zu beachtende Punkte drin. Bei Änderungen an der NIC (in den erweiterten Einstellungen im Gerätemanager oder in der Registry) oder dem HV Switch auch mal den HV neu starten. Steht explizit da drin, Thema VMQ z.B.. Ich hab auch extra - leider mehrfach - ab und an netcfg -d gebrauchen müssen inkl. anschl. Neustart und kompletter Neukonfiguration der NICs und der HV Switche am HV.
Generell sieht es erst einmal nicht so aus als wären deine Probleme mit meinen ehem. Problemen vergleichbar.
Ich nehme an du hast bei dem Hyper V Server eine separate NIC ausschließlich für den Hyper V zur Verwaltung und das ist auch eine der 350er Intel NIC. Wie verhält es sich mit der, auch diese Probleme? Der erste Punkt ist doch: gibt es wesentliche Unterschiede in den Übertragungsraten zwischen ext. Maschinen und dem Hyper V (über einen ext. Switch), ext. Maschinen und den HV Gästen (über einen ext. Switch) und zwischen dem Hyper V und seinen Gästen (einmal über ext. Switch und einmal intern wenn die HV Verwaltung auf der NIC eines HV Switches aktiviert wurde) und das halt alles mal auf einer niedrigeren Ebene gemessen, iperf bietet sich da an.
Abschließende Frage: ist irgendwo Teaming oder ein sonstige NIC Gruppierung aktiv oder war es mal?
Wie ich dir schon schrieb: einfach nur die Treiber zu installieren nutzt u.U. nicht. In der readme zu den Treibern stehen einige wesentliche zu beachtende Punkte drin. Bei Änderungen an der NIC (in den erweiterten Einstellungen im Gerätemanager oder in der Registry) oder dem HV Switch auch mal den HV neu starten. Steht explizit da drin, Thema VMQ z.B.. Ich hab auch extra - leider mehrfach - ab und an netcfg -d gebrauchen müssen inkl. anschl. Neustart und kompletter Neukonfiguration der NICs und der HV Switche am HV.
Generell sieht es erst einmal nicht so aus als wären deine Probleme mit meinen ehem. Problemen vergleichbar.
Hab einen virtuellen 2016 installiert, läuft einwandfrei!
Wieso habe ich nur 2019 installiert?!!!
Wieso habe ich nur 2019 installiert?!!!
Ich habe alle 16 sinnvollen Kombinationen an Betriebssystemen mit einer gewissen Geduld ausprobiert (Host + Gast je 2008R2, 2016 und 2019, nachträglich auch noch 2012R2) und meist auch alles von null an installiert: das Problem trat ausschließlich auf wenn der Host ein 2019 war und der Gast nicht.
Moin @ alle Mitleidenden,
habe die letzte und diese Woche einige Tage in das selbe Problem ungeplant investieren müssen. 😰
Kurz vor der Verzweiflung habe ich vor einigen Stunden dann aber einen Durchbruch gehabt. 😌
Zusammenfassung:
Das Problem tritt nur in Verbindung mit X722 & 1G UPLINK & HV2019 & VM < WIN 2019 auf.
Nun zur Lösung / Workaround:
Ich habe nun in jeden Server für 1G Uplinks eine zusätzliche, dualport I350 basierte Netzwerkkarte für je ~ 150,- verbaut
und siehe da die VMs bringen per SMB wieder 112 - 113 MBs. 🙏😃🤪
Mit aktiviertem SR-IOV & VMQ.
https://www.intel.de/content/www/de/de/ethernet-products/gigabit-server- ...
Es liegt somit definitiv am X722, der im Kern ein 10-40G Chipsatz ist, 1G kann dieser nur aus Kompatibilitätsgründen.
Ob das Problem auch mit einem 10G Uplink passiert, kann ich noch nicht sagen, aber in spätestens 2-3 Wochen,
da bekommt einer der Besitzer einen neuen ARUBA-Core mit 10G.
Werde auch den Intel Support noch stressen, wird aber erst nächste Woche was werden.
Ich bin jetzt erst mal glücklich, dass ich den neuen HV-Cluster, welcher am Freitag beim Kunden mit 1G Uplinks in Betrieb gehen wird,
nicht in einer Nacht und Nebelaktion, auf 2016 downgraden muss. Die 300,- für die beiden Adapter sind bei einem Systempreis von 50K (incl. SAN) für mich persönlich erst einmal vollkommen irrelevant.
Grüsse aus BaWü
Alex
habe die letzte und diese Woche einige Tage in das selbe Problem ungeplant investieren müssen. 😰
Kurz vor der Verzweiflung habe ich vor einigen Stunden dann aber einen Durchbruch gehabt. 😌
Zusammenfassung:
Das Problem tritt nur in Verbindung mit X722 & 1G UPLINK & HV2019 & VM < WIN 2019 auf.
Nun zur Lösung / Workaround:
Ich habe nun in jeden Server für 1G Uplinks eine zusätzliche, dualport I350 basierte Netzwerkkarte für je ~ 150,- verbaut
und siehe da die VMs bringen per SMB wieder 112 - 113 MBs. 🙏😃🤪
Mit aktiviertem SR-IOV & VMQ.
https://www.intel.de/content/www/de/de/ethernet-products/gigabit-server- ...
Es liegt somit definitiv am X722, der im Kern ein 10-40G Chipsatz ist, 1G kann dieser nur aus Kompatibilitätsgründen.
Ob das Problem auch mit einem 10G Uplink passiert, kann ich noch nicht sagen, aber in spätestens 2-3 Wochen,
da bekommt einer der Besitzer einen neuen ARUBA-Core mit 10G.
Werde auch den Intel Support noch stressen, wird aber erst nächste Woche was werden.
Ich bin jetzt erst mal glücklich, dass ich den neuen HV-Cluster, welcher am Freitag beim Kunden mit 1G Uplinks in Betrieb gehen wird,
nicht in einer Nacht und Nebelaktion, auf 2016 downgraden muss. Die 300,- für die beiden Adapter sind bei einem Systempreis von 50K (incl. SAN) für mich persönlich erst einmal vollkommen irrelevant.
Grüsse aus BaWü
Alex
Moin...
bei 10G würde ich SFP+ nutzen wollen, Kupfer wird deutlich zu heiß....
Frank
bei 10G würde ich SFP+ nutzen wollen, Kupfer wird deutlich zu heiß....
Frank
Moin Frank,
da muss ich dir widersprechen.
Wir verbinden die Server immer über 10G Kupfer zum Core.
Zum einen ist es eine Budgetfrage. Eine LWL Verbindung kostet bei DACs mind. 100,- mehr und bei GBICs + Kabel kommst man locker auf ~ 500,- mehr pro Verbindung.
(ich weis, dass es weit günstiger geht, aber nicht wenn mann auf Kompatibilität und Zertifizierung achtet)
Zum Anderen kommt der Faktor Kompatibilität hinzu, der bei LWL nicht zu unterschätzen ist, besonders beim Einsatz von DACs.
Bei Kupfer hingegen gibt es keine Kompatibilitätsprobleme, höchstens Qualitätsprobleme bei den Patchkabeln.
Core zum Verteiler (>25m) binden wir bei 10G wiederum immer über LWL ab.
Grüsse aus BaWü
Alex
da muss ich dir widersprechen.
Wir verbinden die Server immer über 10G Kupfer zum Core.
Zum einen ist es eine Budgetfrage. Eine LWL Verbindung kostet bei DACs mind. 100,- mehr und bei GBICs + Kabel kommst man locker auf ~ 500,- mehr pro Verbindung.
(ich weis, dass es weit günstiger geht, aber nicht wenn mann auf Kompatibilität und Zertifizierung achtet)
Zum Anderen kommt der Faktor Kompatibilität hinzu, der bei LWL nicht zu unterschätzen ist, besonders beim Einsatz von DACs.
Bei Kupfer hingegen gibt es keine Kompatibilitätsprobleme, höchstens Qualitätsprobleme bei den Patchkabeln.
Core zum Verteiler (>25m) binden wir bei 10G wiederum immer über LWL ab.
Grüsse aus BaWü
Alex
Moin,
Zum einen ist es eine Budgetfrage. Eine LWL Verbindung kostet bei DACs mind. 100,- mehr und bei GBICs + Kabel kommst man locker auf ~ 500,- mehr pro Verbindung.
(ich weis, dass es weit günstiger geht, aber nicht wenn mann auf Kompatibilität und Zertifizierung achtet)
Zum Anderen kommt der Faktor Kompatibilität hinzu, der bei LWL nicht zu unterschätzen ist, besonders beim Einsatz von DACs.
Bei Kupfer hingegen gibt es keine Kompatibilitätsprobleme, höchstens Qualitätsprobleme bei den Patchkabeln.
Core zum Verteiler (>25m) binden wir bei 10G wiederum immer über LWL ab.
Grüsse aus BaWü
Alex
Frank
da muss ich dir widersprechen.
Wir verbinden die Server immer über 10G Kupfer zum Core.
ich sag ja nicht, das es nicht geht... sondern nur das es ziemlich warm wird... Wir verbinden die Server immer über 10G Kupfer zum Core.
Zum einen ist es eine Budgetfrage. Eine LWL Verbindung kostet bei DACs mind. 100,- mehr und bei GBICs + Kabel kommst man locker auf ~ 500,- mehr pro Verbindung.
(ich weis, dass es weit günstiger geht, aber nicht wenn mann auf Kompatibilität und Zertifizierung achtet)
Zum Anderen kommt der Faktor Kompatibilität hinzu, der bei LWL nicht zu unterschätzen ist, besonders beim Einsatz von DACs.
Bei Kupfer hingegen gibt es keine Kompatibilitätsprobleme, höchstens Qualitätsprobleme bei den Patchkabeln.
Core zum Verteiler (>25m) binden wir bei 10G wiederum immer über LWL ab.
Grüsse aus BaWü
Alex
Moin Bonbastler,
du solltest deinen Post im Bezug auf den X722 Adapter korrigieren, ich fürchte du bist hier auf denselben Irrtum reingefallen wie ich selber.
Deine Annahme, dass du ein Problem mit einem X722 NIC hast, stammt bestimmt daher, weil der Gerätemanager dir das vorgaukelt.
Leider gibt es bei Intel schon seit Längerem einen „BUG“ welcher bei der Installation der Treiber entweder den falschen Treiber installiert und oder den NIC falsch benennt. ☹
Auszug Readme
---
"Incorrect branding strings
Devices based on the Intel(R) Ethernet Controller X550 and Intel Ethernet
Controller X700 series may display incorrect branding strings in Windows Device Manager. This issue does not affect the functionality of the device. This issue only affects Microsoft* Windows Server* 2016."
---
In meinem Fall wurden die X557 Onboard-NICs ebenfalls als X722er erkannt.
Dein Board dürfte alleine schon aufgrund des Releasedatums (<2018) keine X722er NICs haben.
Der X722er Chipsatz wurde erst 2018 gelauncht.
Habe diesbezüglich vor einer Woche ein Supportcase bei Intel eröffnet, bisher gab es jedoch keine brauchbaren Neuigkeiten. ☹
Halte die Mannschaft auf dem laufenden sobald was Neues reinkommt.
Grüsse aus BaWü
Alex
du solltest deinen Post im Bezug auf den X722 Adapter korrigieren, ich fürchte du bist hier auf denselben Irrtum reingefallen wie ich selber.
Deine Annahme, dass du ein Problem mit einem X722 NIC hast, stammt bestimmt daher, weil der Gerätemanager dir das vorgaukelt.
Leider gibt es bei Intel schon seit Längerem einen „BUG“ welcher bei der Installation der Treiber entweder den falschen Treiber installiert und oder den NIC falsch benennt. ☹
Auszug Readme
---
"Incorrect branding strings
Devices based on the Intel(R) Ethernet Controller X550 and Intel Ethernet
Controller X700 series may display incorrect branding strings in Windows Device Manager. This issue does not affect the functionality of the device. This issue only affects Microsoft* Windows Server* 2016."
---
In meinem Fall wurden die X557 Onboard-NICs ebenfalls als X722er erkannt.
Dein Board dürfte alleine schon aufgrund des Releasedatums (<2018) keine X722er NICs haben.
Der X722er Chipsatz wurde erst 2018 gelauncht.
Habe diesbezüglich vor einer Woche ein Supportcase bei Intel eröffnet, bisher gab es jedoch keine brauchbaren Neuigkeiten. ☹
Halte die Mannschaft auf dem laufenden sobald was Neues reinkommt.
Grüsse aus BaWü
Alex
Hallo Alex,
das X11SPM-F hat wirklich X722 NIC onboard. Die Treiberdateien wurden auch ersetzt durch die aus dem jeweiligen Paket, hab das mehrfach penibel vor- und rückwärts kontrolliert. Das Problem tritt nur bei Server 2019 auf.
Grüße
der bon
das X11SPM-F hat wirklich X722 NIC onboard. Die Treiberdateien wurden auch ersetzt durch die aus dem jeweiligen Paket, hab das mehrfach penibel vor- und rückwärts kontrolliert. Das Problem tritt nur bei Server 2019 auf.
Grüße
der bon
Moin Bon,
ich widerspreche dir nur äusserst ungern, aber schau dir mal bitte den Anhang an.
Du hast exakt das gleiche Problem mit den NICs wie ich.
Gruss Alex
P.S. der Intel Support hat sich heute gemeldet, die sind an dem Problem dran.
ich widerspreche dir nur äusserst ungern, aber schau dir mal bitte den Anhang an.
Du hast exakt das gleiche Problem mit den NICs wie ich.
Gruss Alex
P.S. der Intel Support hat sich heute gemeldet, die sind an dem Problem dran.
Hallo Alex,
ich bin nicht beratungsresistent. Wenn es zur Sache sinnvoll beiträgt dann widersprich mir gern ;)
Wir haben mehrere X11SPM-F verwendet. Der von dir rot eingerahmte NIC Chip ist die für die -TF Boards (10GB RJ45). Weder der Chip noch der zugehörige Konnektor (ein klein wenig weiter rechts) ist bei den -F Boards bestückt. Auf den -F Boards sind die LAN1/2 Konnektoren rechts daneben und die Marvell 88E1512 Phy Transceiver bestückt, siehe Handbuch S. 9 und 10.
Gruss bon
ich bin nicht beratungsresistent. Wenn es zur Sache sinnvoll beiträgt dann widersprich mir gern ;)
Wir haben mehrere X11SPM-F verwendet. Der von dir rot eingerahmte NIC Chip ist die für die -TF Boards (10GB RJ45). Weder der Chip noch der zugehörige Konnektor (ein klein wenig weiter rechts) ist bei den -F Boards bestückt. Auf den -F Boards sind die LAN1/2 Konnektoren rechts daneben und die Marvell 88E1512 Phy Transceiver bestückt, siehe Handbuch S. 9 und 10.
Gruss bon
Moin Bon,
bin es auch nicht.
Habe die Marvell's entdeckt, siehe aktualisiertes Bild.
Bin kein SuperMicro Experte, wir arbeiten mit Intel Hardware.
Nun verstehe ich aber nicht wie du das mit "Hardware sind zwei fast identische neue Maschinen (MB Supermicro X11SPM-F mit 2x 1 GB Intel X722 onBoard NIC“ meinst, onBoard habe ich nichts von X722er entdeckt und deswegen geschrieben.
---
Ist aber auch zweitrangig, wenn du mit optionalen X722er NICs auch das Problem hast, dann hat der Treiber wahrscheinlich generell einen "Schuss" unabhängig ob mit falsch erkannten X557er oder mit richtigen X722er.
Interessant ...
Grüsse aus BaWü
Alex
bin es auch nicht.
Habe die Marvell's entdeckt, siehe aktualisiertes Bild.
Bin kein SuperMicro Experte, wir arbeiten mit Intel Hardware.
Nun verstehe ich aber nicht wie du das mit "Hardware sind zwei fast identische neue Maschinen (MB Supermicro X11SPM-F mit 2x 1 GB Intel X722 onBoard NIC“ meinst, onBoard habe ich nichts von X722er entdeckt und deswegen geschrieben.
---
Ist aber auch zweitrangig, wenn du mit optionalen X722er NICs auch das Problem hast, dann hat der Treiber wahrscheinlich generell einen "Schuss" unabhängig ob mit falsch erkannten X557er oder mit richtigen X722er.
Interessant ...
Grüsse aus BaWü
Alex
Hallo Frank,
zu deiner Information, das ist vielleicht ein Verständnisproblem: der Unterschied zwischen Netzwerkkarte, deren benötigten Treiber und dem Transceiver der die physische Verbindung zur Außenwelt / dem Anschluss herstellt.
Die onboard NIC auf diesen Mainboards (allen Mainboards der X11SPM Serie und vmtl. auch den von dir verwendeten Mainboards) sind Intel X722. Diese sind im Intel 'Lewisburg' PCH Chipsatz integriert und daher benötigen die auch Intel Treiber für X722. Die 1 GB Transceiver (real world connectoren für 1 GB per RJ45 / copper) von den X11SPM-F (die Mainboards welche das Problem haben, siehe 1. Post) sind von Marvel und das spielt treibertechnisch erstmal keine Rolle da diese hinter den NICs angesiedelt sind und keine eigenen Treiber haben oder benötigen. Siehe dazu auch Intel Supportmatrix S. 3 ff. mit der Unterstützung NIC und passendem Transceiver, z.B. auch wg. der X557 Transceiver für Copper 10 GbE welche ihr wohl verwendet habt.
Die temporär verwendeten NIC auf Einsteckkarten waren Intel i210 und i350. Damit gab und gibt es keine Probleme, hatte ich auch so geschrieben.
Gruß, der bon
zu deiner Information, das ist vielleicht ein Verständnisproblem: der Unterschied zwischen Netzwerkkarte, deren benötigten Treiber und dem Transceiver der die physische Verbindung zur Außenwelt / dem Anschluss herstellt.
Die onboard NIC auf diesen Mainboards (allen Mainboards der X11SPM Serie und vmtl. auch den von dir verwendeten Mainboards) sind Intel X722. Diese sind im Intel 'Lewisburg' PCH Chipsatz integriert und daher benötigen die auch Intel Treiber für X722. Die 1 GB Transceiver (real world connectoren für 1 GB per RJ45 / copper) von den X11SPM-F (die Mainboards welche das Problem haben, siehe 1. Post) sind von Marvel und das spielt treibertechnisch erstmal keine Rolle da diese hinter den NICs angesiedelt sind und keine eigenen Treiber haben oder benötigen. Siehe dazu auch Intel Supportmatrix S. 3 ff. mit der Unterstützung NIC und passendem Transceiver, z.B. auch wg. der X557 Transceiver für Copper 10 GbE welche ihr wohl verwendet habt.
Die temporär verwendeten NIC auf Einsteckkarten waren Intel i210 und i350. Damit gab und gibt es keine Probleme, hatte ich auch so geschrieben.
Gruß, der bon
Moin Bon,
Frank ist auch gut ... 🙃
OK, der Hinweis ist gut und ich habe auch schon was passendes in form eines Bildes dazu gefunden.
Verstanden habe ich es zwar noch nicht so ganz, es ist aber auch noch sehr früh am Morgen.
Man lernt eben nie aus ...
Grüsse aus BaWü
Alex
Frank ist auch gut ... 🙃
OK, der Hinweis ist gut und ich habe auch schon was passendes in form eines Bildes dazu gefunden.
Verstanden habe ich es zwar noch nicht so ganz, es ist aber auch noch sehr früh am Morgen.
Man lernt eben nie aus ...
Grüsse aus BaWü
Alex
Moin Bon,
der Groschen ist soeben glaube ich gefallen.
Bei den OnboardNICs steckt die Funktionalität/Logik im Chipsatz (C621/X722), die X557/Marvell's übernehmen hierbei lediglich die physikalische Verbindungsschicht.
Ähnlich wie bei einem SFP/SFP+ Switch, die Funktionalität/Logik sitzt im Switch, die Verbindungschicht übernimmt der jeweilige GBIC.
Richtig verstanden?
Gruss Alex
der Groschen ist soeben glaube ich gefallen.
Bei den OnboardNICs steckt die Funktionalität/Logik im Chipsatz (C621/X722), die X557/Marvell's übernehmen hierbei lediglich die physikalische Verbindungsschicht.
Ähnlich wie bei einem SFP/SFP+ Switch, die Funktionalität/Logik sitzt im Switch, die Verbindungschicht übernimmt der jeweilige GBIC.
Richtig verstanden?
Gruss Alex
Hallo Alex,
ganz genau so ist es. Schönes Bild, hätte ich nach einer guten Darstellung gesucht: das wär's, Handbuch S. 19.
Gruß
der bon
ganz genau so ist es. Schönes Bild, hätte ich nach einer guten Darstellung gesucht: das wär's, Handbuch S. 19.
Gruß
der bon
Moin Bon,
mein Hirn arbeitet besser mit visuellem Material. 😜
Gruss und Dank
Alex
mein Hirn arbeitet besser mit visuellem Material. 😜
Gruss und Dank
Alex
Moin Bon,
zurück zu der Problematik.
Wenn ich nun alles zusammenlege, dann entsteht das Problem nur bei der folgenden Konstellation.
HV-OS: 2019
VM-OS: irrelevant (konnten das Problem mit 2012R2/2016/2019 nachstellen)
V-Switch nach extern über X722(LOGIK) und 1G Uplink.
Die verwendete physikalische Übertragungschicht (X557 oder Marvell) ist dabei irrelevant.
Bei Verwendung eines "eigenständigen" Adapters basierend auf I350, treten hingegen keine Probleme auf.
???
Gruss Alex
zurück zu der Problematik.
Wenn ich nun alles zusammenlege, dann entsteht das Problem nur bei der folgenden Konstellation.
HV-OS: 2019
VM-OS: irrelevant (konnten das Problem mit 2012R2/2016/2019 nachstellen)
V-Switch nach extern über X722(LOGIK) und 1G Uplink.
Die verwendete physikalische Übertragungschicht (X557 oder Marvell) ist dabei irrelevant.
Bei Verwendung eines "eigenständigen" Adapters basierend auf I350, treten hingegen keine Probleme auf.
???
Gruss Alex
So ähnlich, siehe Eröffnungspost.
Das Problem trat bei uns mehrfach reproduzierbar ausschließlich auf wenn der Hyper V ein 2019 und der Gast kein 2019 (2008R2, 2012R2, 2016) war. Mit Server 2016 oder Server 2012R2 als Hyper V und einem beliebigen Server als Gast (2008R2, 2012R2, 2016, 2019) trat das Problem nicht auf. Bei Verwendung eines eigenständigen NIC Adapters mit i210 oder i350 trat das Problem auch nicht auf. Ob die bei der X722 verwendeten phys. Transceiver (in dem von mir geschilderten Fall die Marvell 1GB Phy Transceiver) eine Rolle spielen konnte ich bisher mangels Technikverfügbarkeit bzw. mangelnder Zeit nicht weiter nachstellen. Der User 137846 hatte weiter oben am 29.12. gegen 10:52 geschrieben dass er diese Probleme nicht nachstellen konnte, keine Ahnung was für ein Board der genau benutzt hat.
Fakt ist: mit einer Standardinstallation, mehreren der damals verfügbaren originalen Treibern und den originalen Einstellungen dafür trat das Problem reproduzierbar auf. Wir haben an den Systemen derart viel rumgebastelt (im positiven Sinne) dass der (insbes. der einfachste / kürzeste) Weg zum Ziel nicht mehr komplett reproduzierbar ist. Das Ziel war irgendwann erreicht. Mangels weitere Zeit und alternativer HW zum Nachstellen und Testen habe ich das bei uns vor Monaten als vorläufig gelöst beiseite legen müssen. Einem anderen Benutzer hier im Forum (s.o.) welcher vmtl. das gleiche Problem hatte habe ich angeboten das mit ihm durchzuspielen aber er hat das Angebot nicht wahrgenommen, so blieb auch mir die einfache Möglichkeit verwehrt das Problem - sofern es aktuell noch besteht - genauer zu dokumentieren und einen effektiven Lösungsweg (auch hier) zu offerieren.
Das Problem trat bei uns mehrfach reproduzierbar ausschließlich auf wenn der Hyper V ein 2019 und der Gast kein 2019 (2008R2, 2012R2, 2016) war. Mit Server 2016 oder Server 2012R2 als Hyper V und einem beliebigen Server als Gast (2008R2, 2012R2, 2016, 2019) trat das Problem nicht auf. Bei Verwendung eines eigenständigen NIC Adapters mit i210 oder i350 trat das Problem auch nicht auf. Ob die bei der X722 verwendeten phys. Transceiver (in dem von mir geschilderten Fall die Marvell 1GB Phy Transceiver) eine Rolle spielen konnte ich bisher mangels Technikverfügbarkeit bzw. mangelnder Zeit nicht weiter nachstellen. Der User 137846 hatte weiter oben am 29.12. gegen 10:52 geschrieben dass er diese Probleme nicht nachstellen konnte, keine Ahnung was für ein Board der genau benutzt hat.
Fakt ist: mit einer Standardinstallation, mehreren der damals verfügbaren originalen Treibern und den originalen Einstellungen dafür trat das Problem reproduzierbar auf. Wir haben an den Systemen derart viel rumgebastelt (im positiven Sinne) dass der (insbes. der einfachste / kürzeste) Weg zum Ziel nicht mehr komplett reproduzierbar ist. Das Ziel war irgendwann erreicht. Mangels weitere Zeit und alternativer HW zum Nachstellen und Testen habe ich das bei uns vor Monaten als vorläufig gelöst beiseite legen müssen. Einem anderen Benutzer hier im Forum (s.o.) welcher vmtl. das gleiche Problem hatte habe ich angeboten das mit ihm durchzuspielen aber er hat das Angebot nicht wahrgenommen, so blieb auch mir die einfache Möglichkeit verwehrt das Problem - sofern es aktuell noch besteht - genauer zu dokumentieren und einen effektiven Lösungsweg (auch hier) zu offerieren.
Moin Bon,
das mit HV 2019 & VM 219 kann ich nur zum Teil bestätigen.
VM 2019 --> HV 2019 --> 1G SWITCH --> Client W10 konnte ich keine Probleme feststellen.
Jedoch bei VM 2019 --> HV 2019 --> 1G SWITCH --> HV 2019 --> VM 2019 sehr wohl.
Die Lösung mit dem I350 setzen wir aktuell auch bei allen aktuellen Systemen mit 1G Switchen dahinter ein.
Ich habe vor 1,5 Wochen einen Supportcase bei Intel eröffnet und gebeten das ganze im Lab mal nachzustellen, siehe Anhang.
Bei allem was ich bisher gelesen habe, sollte die Lösung meines Problems auch deines beseitigen.
Bleibt nun abzuwarten.
Grüsse aus BaWü
Alex
P.S. Die Jungs vom Intel Support haben von mir auch den Link zu diesem Post hier bekommen.
das mit HV 2019 & VM 219 kann ich nur zum Teil bestätigen.
VM 2019 --> HV 2019 --> 1G SWITCH --> Client W10 konnte ich keine Probleme feststellen.
Jedoch bei VM 2019 --> HV 2019 --> 1G SWITCH --> HV 2019 --> VM 2019 sehr wohl.
Die Lösung mit dem I350 setzen wir aktuell auch bei allen aktuellen Systemen mit 1G Switchen dahinter ein.
Ich habe vor 1,5 Wochen einen Supportcase bei Intel eröffnet und gebeten das ganze im Lab mal nachzustellen, siehe Anhang.
Bei allem was ich bisher gelesen habe, sollte die Lösung meines Problems auch deines beseitigen.
Bleibt nun abzuwarten.
Grüsse aus BaWü
Alex
P.S. Die Jungs vom Intel Support haben von mir auch den Link zu diesem Post hier bekommen.
Hi Bon,
habe Update, siehe Mail die ich gerade an den Intel Support geschickt habe.
---
Hi Christian,
it’s a little bit cracy.
We prepare these week a new system for a customer.
The hardware is the same like the systems before, the only differences are a bunch of microsoft updates for the MS server 2019 and
a new version of the chipset driver.
Now, we can’t reproduce the issue!?!
The last day’s we try some different configurations.
HV was always MS Server 2019
VMQ & SRIOV are both enabled (BIOS, NIC, V-SWITCH, VM).
VM: MS Server 2019 MS Server 2019 112 – 113 MB’s
VM: MS Server 2016 MS Server 2016 112 – 113 MB’s
VM: MS Server 2012R2 MS Server 2012R2 112 – 113 MB’s
At the moment we, check the whole configuration (BIOS/OS/HV), to make sure that everything corresponds to the previous system.
---
Grüsse aus BaWü
Alex
habe Update, siehe Mail die ich gerade an den Intel Support geschickt habe.
---
Hi Christian,
it’s a little bit cracy.
We prepare these week a new system for a customer.
The hardware is the same like the systems before, the only differences are a bunch of microsoft updates for the MS server 2019 and
a new version of the chipset driver.
Now, we can’t reproduce the issue!?!
The last day’s we try some different configurations.
HV was always MS Server 2019
VMQ & SRIOV are both enabled (BIOS, NIC, V-SWITCH, VM).
VM: MS Server 2019 MS Server 2019 112 – 113 MB’s
VM: MS Server 2016 MS Server 2016 112 – 113 MB’s
VM: MS Server 2012R2 MS Server 2012R2 112 – 113 MB’s
At the moment we, check the whole configuration (BIOS/OS/HV), to make sure that everything corresponds to the previous system.
---
Grüsse aus BaWü
Alex
Hallo Alex,
danke erstmal für deine Bemühungen.
Das Problem tritt ja nicht in der Kommunikation der VM untereinander innerhalb des Host über den HV Switch auf sondern zu 'beliebigen' Clients (physisch und virtuell) nach außen über die NIC. Das geht aus deren Beschreibung nicht so eindeutig hervor ob die das Szenario auch so umgesetzt haben.
Gruß
der Bon
danke erstmal für deine Bemühungen.
Das Problem tritt ja nicht in der Kommunikation der VM untereinander innerhalb des Host über den HV Switch auf sondern zu 'beliebigen' Clients (physisch und virtuell) nach außen über die NIC. Das geht aus deren Beschreibung nicht so eindeutig hervor ob die das Szenario auch so umgesetzt haben.
Gruß
der Bon
Moin Bon,
wenn ich etwas anfasse, dann richtig.
"Das Problem tritt ja nicht in der Kommunikation der VM untereinander innerhalb des Host über den HV Switch auf sondern zu 'beliebigen' Clients (physisch und virtuell) nach außen über die NIC."
Wir haben immer mit 2 HVs getestet.
HV01(2019) mit VM 2019 <--> Hardwareswitch <--> HV02(2019) mit VM 2019
HV01(2019) mit VM 2016 <--> Hardwareswitch <--> HV02(2019) mit VM 2016
HV01(2019) mit VM 2012R2 <--> Hardwareswitch <--> HV02(2019) mit VM 2012R2
Das müsste, wenn ich mich nicht täusche, auch dein Szenario abdecken.
Gruss Alex
wenn ich etwas anfasse, dann richtig.
"Das Problem tritt ja nicht in der Kommunikation der VM untereinander innerhalb des Host über den HV Switch auf sondern zu 'beliebigen' Clients (physisch und virtuell) nach außen über die NIC."
Wir haben immer mit 2 HVs getestet.
HV01(2019) mit VM 2019 <--> Hardwareswitch <--> HV02(2019) mit VM 2019
HV01(2019) mit VM 2016 <--> Hardwareswitch <--> HV02(2019) mit VM 2016
HV01(2019) mit VM 2012R2 <--> Hardwareswitch <--> HV02(2019) mit VM 2012R2
Das müsste, wenn ich mich nicht täusche, auch dein Szenario abdecken.
Gruss Alex
Moin Bon,
kam gerade vom Intel Support rein.
---
Hello Alexander,
Thank you for the update in regards to the experience on your end.
We also noticed that the new updates from Microsoft have some impact on our current configurations but in some different scenarios.
We will still continue and try to replicate the issue and see what results we will get over the testing period.
When we get some details we will let you know for sure.
At the same time, if you find out some details on your side, we would be very tankful for additional feedback.
Once again thank you in advance.
---
Lag vielleicht doch nicht an Intel sondern an MS. 😀
Wünsche allen ein schönes Wochenende.
Ich tauche jetzt ab . 😎🤪🤘🏿
Gruss Alex
kam gerade vom Intel Support rein.
---
Hello Alexander,
Thank you for the update in regards to the experience on your end.
We also noticed that the new updates from Microsoft have some impact on our current configurations but in some different scenarios.
We will still continue and try to replicate the issue and see what results we will get over the testing period.
When we get some details we will let you know for sure.
At the same time, if you find out some details on your side, we would be very tankful for additional feedback.
Once again thank you in advance.
---
Lag vielleicht doch nicht an Intel sondern an MS. 😀
Wünsche allen ein schönes Wochenende.
Ich tauche jetzt ab . 😎🤪🤘🏿
Gruss Alex
Moin Bon,
wir haben das System noch bin Anfang nächster Woche.
Wir testen noch das NIC-Teaming und wenn das gut geht dann ist der Fisch für uns geputzt.
Mit welchen Clients hattest du bis jetzt Probleme?
Wir testen unser Setup nochmals mit Win10 Workstation gegen HV2019 und VM2016 & VM2012R2.
Gebe dir Bescheid, sobald die Tests durch sind.
Gruss Alex
wir haben das System noch bin Anfang nächster Woche.
Wir testen noch das NIC-Teaming und wenn das gut geht dann ist der Fisch für uns geputzt.
Mit welchen Clients hattest du bis jetzt Probleme?
Wir testen unser Setup nochmals mit Win10 Workstation gegen HV2019 und VM2016 & VM2012R2.
Gebe dir Bescheid, sobald die Tests durch sind.
Gruss Alex
Moin Bon,
sind durch mit den Tests. 😀🤘🏿
(Anwortmail an Intel)
---
Hi Christian,
today we test the last part, NIC-Teaming (2 x 1Gbit/s), it works fine.
HV01(2019) with VM 2019 <--> Hardwareswitch <--> HV02(2019) with VM 2019 112-113MB/s
HV01(2019) with VM 2016 <--> Hardwareswitch <--> HV02(2019) with VM 2016 112-113MB/s
HV01(2019) with VM 2012R2 <--> Hardwareswitch <--> HV02(2019) with VM 2012R2 112-113MB/s
HV01(2019) with VM 2019 <--> Hardwareswitch <--> Workstation W10 112-113MB/s
HV01(2019) with VM 2016 <--> Hardwareswitch <--> Workstation W10 112-113MB/s
HV01(2019) with VM 2012R2 <--> Hardwareswitch <--> Workstation W10 112-113MB/s
I think our problem is solved. 😀
MS Update ???
Best regards
Alex
---
Gruss Alex
sind durch mit den Tests. 😀🤘🏿
(Anwortmail an Intel)
---
Hi Christian,
today we test the last part, NIC-Teaming (2 x 1Gbit/s), it works fine.
HV01(2019) with VM 2019 <--> Hardwareswitch <--> HV02(2019) with VM 2019 112-113MB/s
HV01(2019) with VM 2016 <--> Hardwareswitch <--> HV02(2019) with VM 2016 112-113MB/s
HV01(2019) with VM 2012R2 <--> Hardwareswitch <--> HV02(2019) with VM 2012R2 112-113MB/s
HV01(2019) with VM 2019 <--> Hardwareswitch <--> Workstation W10 112-113MB/s
HV01(2019) with VM 2016 <--> Hardwareswitch <--> Workstation W10 112-113MB/s
HV01(2019) with VM 2012R2 <--> Hardwareswitch <--> Workstation W10 112-113MB/s
I think our problem is solved. 😀
MS Update ???
Best regards
Alex
---
Gruss Alex
Hallo zusammen,
interessanter Post. So ähnlich habe ich es auch, aber mit einer ganz einfachen Konfiguration, keine VMs, kein „Schnickschnack“, simply Dateitransfer, kein Teaming:
- verschiedene Windows 10 Rechner
- Win2016 Server (Intel)
- Win2019 Server (AMD)
- Netgear 10G switch
- Alle Asus 10G Karte RJ45
- Alle Treibereinstellungen probiert, danach wieder auf Standard gestellt
Aufgabe: Einfach nur eine 24GB Datei vom Server laden.
Win2016 Server -> Windows 10 Rechner konstant 500MByte/sec
Windows 10 RechnerA -> Windows 10 RechnerB konstant 1,09GByte/sec (nvme)
Win2019 Server -> Windows 10 Rechner unberechenbar, startet teilweise bei 500MB/sec, dann drop auf 360KB/sec . Oder „startet“ gleich mit 360KB/Sec.
Bin mit meinem Latein am Ende. Problem scheint doch auf Server2019 fokussiert zu sein. Vielleicht im Zusammenspiel mit AMD.
Update: Es liegt nicht an der Asus Karte, Bei Verwendung einer Intel Karte dasselbe Problem...
interessanter Post. So ähnlich habe ich es auch, aber mit einer ganz einfachen Konfiguration, keine VMs, kein „Schnickschnack“, simply Dateitransfer, kein Teaming:
- verschiedene Windows 10 Rechner
- Win2016 Server (Intel)
- Win2019 Server (AMD)
- Netgear 10G switch
- Alle Asus 10G Karte RJ45
- Alle Treibereinstellungen probiert, danach wieder auf Standard gestellt
Aufgabe: Einfach nur eine 24GB Datei vom Server laden.
Win2016 Server -> Windows 10 Rechner konstant 500MByte/sec
Windows 10 RechnerA -> Windows 10 RechnerB konstant 1,09GByte/sec (nvme)
Win2019 Server -> Windows 10 Rechner unberechenbar, startet teilweise bei 500MB/sec, dann drop auf 360KB/sec . Oder „startet“ gleich mit 360KB/Sec.
Bin mit meinem Latein am Ende. Problem scheint doch auf Server2019 fokussiert zu sein. Vielleicht im Zusammenspiel mit AMD.
Update: Es liegt nicht an der Asus Karte, Bei Verwendung einer Intel Karte dasselbe Problem...
Ich habe/hatte auch das Problem, dass jegliche VM (wie von @MysticFoxDE beschrieben) einen schlechten Durchsatz hatte.
Nachdem ich auf den 2019er VMs den Panda Virenschutz deinstallierte, funktionierten diese zumindest ohne Probleme.
Problem bei den 2010R2er VMs bleibt jedoch bestehen.
Alles was ich bisher probierte, brachte nichts:
Habe dann Tests mit einer 14,99€ "teuren" Realtek USB GbE Family gemacht. Und voilà: alles funktioniert.
Keine Ahnung ob es am Treiber oder an den Einstellungen hakt. Aber kann bestätigen, dass es hier definitiv Probleme gibt.
@MysticFoxDE:
was hat denn der Intel-Support dir nun geantwortet? Wie wollen die denn weiter vorgehen?
Grüße
Patrick
Nachdem ich auf den 2019er VMs den Panda Virenschutz deinstallierte, funktionierten diese zumindest ohne Probleme.
Problem bei den 2010R2er VMs bleibt jedoch bestehen.
Alles was ich bisher probierte, brachte nichts:
- aktuellen Treiber installiert
- aktuelle Firmware von Lenovo installiert
- Panda Virenschutz deinstalliert
- VMQ deaktiviert (ist bei 1GBit NICs ja sowieso nicht standardmäßig aktiviert)
- Flußsteuerung und Puffergrößen auf die empfohlenen Einstellungen von Intel gesetzt (klick)
- Direkt in den VM-Einstellungen die "Warteschlange für virtuelle Computer" deaktiviert
- IPsec-Taskabladung deaktiviert
- RSC deaktiviert (klick)
- Large send offload deaktiviert
- TCP- und UDP-Prüfsummenabladung deaktiviert (sowohl auf physischer als auch auf virtueller NIC)
- Upgrade der VM von Gen1 auf Gen2 (klick)
- ...
Habe dann Tests mit einer 14,99€ "teuren" Realtek USB GbE Family gemacht. Und voilà: alles funktioniert.
Keine Ahnung ob es am Treiber oder an den Einstellungen hakt. Aber kann bestätigen, dass es hier definitiv Probleme gibt.
@MysticFoxDE:
was hat denn der Intel-Support dir nun geantwortet? Wie wollen die denn weiter vorgehen?
Grüße
Patrick
Hi Patrick,
wir können das Problem nicht mehr reproduzieren.
Nach mehrfacher Prüfung entspricht die Konfiguration des jetzigen "Labs" exakt der Konfiguration, der vorherigen Systeme.
Der einzige Unterschied ist der Patchlevel des 2019er Servers, die jetzige Lab ist auf dem allerneusten Stand gegen MS Updates, nicht WSUS.
---
VMQ deaktiviert (ist bei 1GBit NICs ja sowieso nicht standardmäßig aktiviert)
Flußsteuerung und Puffergrößen auf die empfohlenen Einstellungen von Intel gesetzt (klick)
Direkt in den VM-Einstellungen die "Warteschlange für virtuelle Computer" deaktiviert
IPsec-Taskabladung deaktiviert
RSC deaktiviert (klick)
Large send offload deaktiviert
TCP- und UDP-Prüfsummenabladung deaktiviert (sowohl auf physischer als auch auf virtueller NIC)
---
Hatten wir früher auch gemacht, ist aber nicht mehr notwendig, zumindest nicht bei unserem Szenario.
Grüsse aus BaWü
Alex
wir können das Problem nicht mehr reproduzieren.
Nach mehrfacher Prüfung entspricht die Konfiguration des jetzigen "Labs" exakt der Konfiguration, der vorherigen Systeme.
Der einzige Unterschied ist der Patchlevel des 2019er Servers, die jetzige Lab ist auf dem allerneusten Stand gegen MS Updates, nicht WSUS.
---
VMQ deaktiviert (ist bei 1GBit NICs ja sowieso nicht standardmäßig aktiviert)
Flußsteuerung und Puffergrößen auf die empfohlenen Einstellungen von Intel gesetzt (klick)
Direkt in den VM-Einstellungen die "Warteschlange für virtuelle Computer" deaktiviert
IPsec-Taskabladung deaktiviert
RSC deaktiviert (klick)
Large send offload deaktiviert
TCP- und UDP-Prüfsummenabladung deaktiviert (sowohl auf physischer als auch auf virtueller NIC)
---
Hatten wir früher auch gemacht, ist aber nicht mehr notwendig, zumindest nicht bei unserem Szenario.
Grüsse aus BaWü
Alex
Danke für deine Rückmeldung.
Das soll nun einer noch verstehen...
Grüße
Patrick
Zitat von @MysticFoxDE:
Der einzige Unterschied ist der Patchlevel des 2019er Servers, die jetzige Lab ist auf dem allerneusten Stand gegen MS Updates, nicht WSUS.
Bei mir auch alles aktuell (ohne WSUS) und trotzdem genau die gleichen Symptome wie ihr sie hattet (und scheinbar nun bei euch behoben sind).Der einzige Unterschied ist der Patchlevel des 2019er Servers, die jetzige Lab ist auf dem allerneusten Stand gegen MS Updates, nicht WSUS.
Das soll nun einer noch verstehen...
Grüße
Patrick
Moin Patrick,
bei uns sind die Probleme momentan in Verbindung mit einem NEUEN System nicht mehr nachvollziehbar.
Zumindest nicht, wenn unsere Adapter mit 1G laufen, mit 10G habe ich diese bisher nicht getestet, da keiner unserer Kuden 10G zum Client betreibt.
Die bisherigen 3 Systeme die wir auf 2019 ausgeliefert haben, sind alle mit i350 er nachgerüstet worden und laufen seit dem mit 1G reibungslos.
Versuch mal den folgenden Trick.
Gehe in den Gerätemanager und deinstalliere alle X722 Adapter, danach Hardwareerkennung (Nach geänderter Hardware suchen) ausführen und die Adapter anschliessend neu konfigurieren. Ist lästig, aber ich habe da so eine Vermutung die auf der folgenden jüngsten Erfahrung beruht.
Bei den Tests, die wir die letzten Tage gemacht haben, wurde unter anderem auch ein vierfach Teaming getestet.
Das Ergebnis war OK, aber als ich zwei der vier NICs wieder aus dem Team geschmissen habe, konnte ich dieselben nicht mehr in ein neues Team hinzufügen, die NICs waren über den Servermanager nicht mehr sichtbar (wir nutzen MS-Teaming (Modus --> Switchunabhängig), nicht Intel-Teaming). Die NICs waren erst nach der oben beschriebenen Prozedur über den Servermanager wieder konfigurierbar.
Ich schätze MS muss noch ein paar BUGs mehr beseitigen ... ☹
Wir deaktivieren ferner auf allen Adaptern IPv6, wollte ich nur der Vollständigkeit halber erwähnen.
Grüsse aus BaWü
Alex
bei uns sind die Probleme momentan in Verbindung mit einem NEUEN System nicht mehr nachvollziehbar.
Zumindest nicht, wenn unsere Adapter mit 1G laufen, mit 10G habe ich diese bisher nicht getestet, da keiner unserer Kuden 10G zum Client betreibt.
Die bisherigen 3 Systeme die wir auf 2019 ausgeliefert haben, sind alle mit i350 er nachgerüstet worden und laufen seit dem mit 1G reibungslos.
Versuch mal den folgenden Trick.
Gehe in den Gerätemanager und deinstalliere alle X722 Adapter, danach Hardwareerkennung (Nach geänderter Hardware suchen) ausführen und die Adapter anschliessend neu konfigurieren. Ist lästig, aber ich habe da so eine Vermutung die auf der folgenden jüngsten Erfahrung beruht.
Bei den Tests, die wir die letzten Tage gemacht haben, wurde unter anderem auch ein vierfach Teaming getestet.
Das Ergebnis war OK, aber als ich zwei der vier NICs wieder aus dem Team geschmissen habe, konnte ich dieselben nicht mehr in ein neues Team hinzufügen, die NICs waren über den Servermanager nicht mehr sichtbar (wir nutzen MS-Teaming (Modus --> Switchunabhängig), nicht Intel-Teaming). Die NICs waren erst nach der oben beschriebenen Prozedur über den Servermanager wieder konfigurierbar.
Ich schätze MS muss noch ein paar BUGs mehr beseitigen ... ☹
Wir deaktivieren ferner auf allen Adaptern IPv6, wollte ich nur der Vollständigkeit halber erwähnen.
Grüsse aus BaWü
Alex
1
Moin Hub22019,
welche Hardware benutzt du für die Server, Mainboard/CPU?
Welchen Storagetyp hat der Server HHD/SSD, SATA/SAS/NVME?
"Win2016 Server -> Windows 10 Rechner konstant 500MByte/sec"
"Win2019 Server -> Windows 10 Rechner unberechenbar, startet teilweise bei 500MB/sec, dann drop auf 360KB/sec . Oder „startet“ gleich mit 360KB/Sec"
???
Es ist etwas kurios, dass bei dir beide, sowohl der 2016er als auch der 2019er spacken ...
Hast du evtl. einseitig Jumboframe eingestellt?
VLAN, Routing dazwischen?
Je mehr Infos um so besser.
Gruss Alex
welche Hardware benutzt du für die Server, Mainboard/CPU?
Welchen Storagetyp hat der Server HHD/SSD, SATA/SAS/NVME?
"Win2016 Server -> Windows 10 Rechner konstant 500MByte/sec"
"Win2019 Server -> Windows 10 Rechner unberechenbar, startet teilweise bei 500MB/sec, dann drop auf 360KB/sec . Oder „startet“ gleich mit 360KB/Sec"
???
Es ist etwas kurios, dass bei dir beide, sowohl der 2016er als auch der 2019er spacken ...
Hast du evtl. einseitig Jumboframe eingestellt?
VLAN, Routing dazwischen?
Je mehr Infos um so besser.
Gruss Alex
Hallo Alex,
hatte nun hier einen thread aufgemacht:
10GBE Filetransfer vom Windows2019 server aus funktioniert nicht
Server2016 Microserver gen8: Sata ssd 6g
Server2019 Microserver gen10: Sata ssd 6g
PCs: nvme
Jumbo überall eingestellt.
Auf dem folgenden Screenshot sieht man auf einen Blick das Problem. Dabei habe ich die beiden unteren Kopiervorgänge gestartet, als beim oberen schon seit 20 Sekunden bei 300kb/sec herumgedümpelt wird. WTF...
Am besten bitte im anderen Thread antworten
hatte nun hier einen thread aufgemacht:
10GBE Filetransfer vom Windows2019 server aus funktioniert nicht
Server2016 Microserver gen8: Sata ssd 6g
Server2019 Microserver gen10: Sata ssd 6g
PCs: nvme
Jumbo überall eingestellt.
Auf dem folgenden Screenshot sieht man auf einen Blick das Problem. Dabei habe ich die beiden unteren Kopiervorgänge gestartet, als beim oberen schon seit 20 Sekunden bei 300kb/sec herumgedümpelt wird. WTF...
Am besten bitte im anderen Thread antworten
Hallo Alex,
danke für deine Tips.
Hätte nun das entfernen und hinzufügen der Adapter probiert.
Auch das deaktivieren von IPv6.
Beides löst leider das Problem nicht
Grüße
Patrick
danke für deine Tips.
Hätte nun das entfernen und hinzufügen der Adapter probiert.
Auch das deaktivieren von IPv6.
Beides löst leider das Problem nicht
Grüße
Patrick
Moin Patrick,
Moin Badger,
wenn Ihr auf dem 2019er Server noch etwas RAM übrig habt, so probiert bitte das folgende.
Generiert bitte mit dem folgenden Tool eine RAM-DISK.
https://sourceforge.net/projects/imdisk-toolkit/
Freigabe drauf und den Test wiederholen.
Ergebnis ???
---
Um bei einem MS Server die vollen Transferraten zu erreichen, sollte man ferner immer die Energieoptionen auf "Hochleistung" setzen!!!
Bei einem 2019er hätte ich euch noch den folgenden Trick.
CMD mit Adminrechten aufmachen und dann die folgenden beiden Befehle ausführen.
1. "powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61"
2. "powercfg.exe -setactive 9d69a0c6-32fb-4d7a-b235-e37b7d0111c0"
3. Unter Energieeinstellungen nachsehen. 😉🤪
Diese Einstellung muss sowohl auf dem HV als auch auf der VM gemacht werden.
Grüsse aus BaWü
Alex
Moin Badger,
wenn Ihr auf dem 2019er Server noch etwas RAM übrig habt, so probiert bitte das folgende.
Generiert bitte mit dem folgenden Tool eine RAM-DISK.
https://sourceforge.net/projects/imdisk-toolkit/
Freigabe drauf und den Test wiederholen.
Ergebnis ???
---
Um bei einem MS Server die vollen Transferraten zu erreichen, sollte man ferner immer die Energieoptionen auf "Hochleistung" setzen!!!
Bei einem 2019er hätte ich euch noch den folgenden Trick.
CMD mit Adminrechten aufmachen und dann die folgenden beiden Befehle ausführen.
1. "powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61"
2. "powercfg.exe -setactive 9d69a0c6-32fb-4d7a-b235-e37b7d0111c0"
3. Unter Energieeinstellungen nachsehen. 😉🤪
Diese Einstellung muss sowohl auf dem HV als auch auf der VM gemacht werden.
Grüsse aus BaWü
Alex
Moin Hub22019,
ergänzend zu dem zuletzt geprosteten.
Du musst unbedingt sicherstellen, dass deine Storage-Hardware die 1GB/s bei einem "single thread / single task" auch packt.
Das bekommen im Normalfall nur PCIe/NVME SSDs hin oder ein leistungsfähiges SAN am Server.
Mit (6G)SATA SSDs wirst du das ohne einen RAID-Verbund 100% nicht hinbekommen.
Wir verwenden in unseren Servern P4800X von Intel als Bootlaufwerke und das angeschlossenen AllFlash-SAN ist auch sehr leistungsfähig,
beide packen bei "single thread" locker > 1000 MB/s.
Grüsse aus BaWü
Alex
ergänzend zu dem zuletzt geprosteten.
Du musst unbedingt sicherstellen, dass deine Storage-Hardware die 1GB/s bei einem "single thread / single task" auch packt.
Das bekommen im Normalfall nur PCIe/NVME SSDs hin oder ein leistungsfähiges SAN am Server.
Mit (6G)SATA SSDs wirst du das ohne einen RAID-Verbund 100% nicht hinbekommen.
Wir verwenden in unseren Servern P4800X von Intel als Bootlaufwerke und das angeschlossenen AllFlash-SAN ist auch sehr leistungsfähig,
beide packen bei "single thread" locker > 1000 MB/s.
Grüsse aus BaWü
Alex
Danke allen - ganz besonders @MysticFoxDE - für eure Hilfe.
Ich konnte nun das Problem lösen. Im Lenovo Forum brachte mir ein User den entscheidenden Hinweis:
Es muss dabei wirklich RSC auf der NIC abgeschaltet werden. Das deaktivieren von RSC am vSwitch löste bei mir das Problem nicht!
@bonbastler:
War dies evt. auch bei deinem Problem die Lösung?
Grüße
Patrick
Ich konnte nun das Problem lösen. Im Lenovo Forum brachte mir ein User den entscheidenden Hinweis:
After trying different drivers, firmware, etc. the only solution I finally found was this:
In the Driver -> Advanced for the NIC:
Recv Segment Coalescing (IPv4) - set to Disabled
Recv Segment Coalescing (IPv6) - set to Disabled
In the Driver -> Advanced for the NIC:
Recv Segment Coalescing (IPv4) - set to Disabled
Recv Segment Coalescing (IPv6) - set to Disabled
Es muss dabei wirklich RSC auf der NIC abgeschaltet werden. Das deaktivieren von RSC am vSwitch löste bei mir das Problem nicht!
@bonbastler:
War dies evt. auch bei deinem Problem die Lösung?
Grüße
Patrick
Auch diesbezüglich noch zur Info:
Wenn der Server 2019 ist, kam es bei mir prinzipiell nicht zu einem Problem. Außer Panda war installiert.
Seit ich RSC deaktiviert habe, funktioniert es auch mit installiertem Panda beträchtlich besser.
Patrick
Wenn der Server 2019 ist, kam es bei mir prinzipiell nicht zu einem Problem. Außer Panda war installiert.
Seit ich RSC deaktiviert habe, funktioniert es auch mit installiertem Panda beträchtlich besser.
Patrick
Hi Patrick,
vielen Dank für diese sehr interessante Info, werde diese im Auge behalten.
Habe soeben das Lab-System welches morgen ausgeliefert wird nochmals hochgefahren und die Einstellungen geprüft,
bei uns sind die Optionen auf "Enabled" ohne Performanceeinbussen. ?!?
Aber dennoch sehr Cool, nun weis ich ja wo ich drehen muss, falls doch welche auftauchen. 👍
Nochmals herzlichen Dank für das Teilen der Lösung.
Gruss Alex
vielen Dank für diese sehr interessante Info, werde diese im Auge behalten.
Habe soeben das Lab-System welches morgen ausgeliefert wird nochmals hochgefahren und die Einstellungen geprüft,
bei uns sind die Optionen auf "Enabled" ohne Performanceeinbussen. ?!?
Aber dennoch sehr Cool, nun weis ich ja wo ich drehen muss, falls doch welche auftauchen. 👍
Nochmals herzlichen Dank für das Teilen der Lösung.
Gruss Alex
Hallo!
Ich möchte hier gerne Einsteigen und unsere Erfahrung teilen:
System: Fujitsu 2540M5 mit 2x X710 10G Karten.
Hyper-V Rolle installiert. Eine 10G Karte als Taggen Uplink für die VM's.
Wir haben angefangen VMs von einem 2012R2 zu migrieren. Das Ganze lief 2 Wochen einwandfrei.
Vor einigen Tagen fingen die Performance Probleme der VMs an:
Datendurchsatz meist unter 22MB/s - oftmals um die 3MB/s. Teilweise lassen sich Dateien nicht öffnen, oder Verbindungen zu einer Oracle DB brechen ab.
Was ich beobachten konnte: Das Kopieren einer ISO Datei mit 1GB hat auf die VM's (2008, 2008R2 und 2012R2) einen Durchsatz von 3MB/s.
2019er VM's bringen allerdings den vollen Durchsatz!
Wir haben dann die internen RJ45 als virtual Switch konfiguriert. Es handelt sich hier um X722 Karten.
Hier zeigt sich exakt das selbe Verhalten.
Kopiere ich nun aber über die 10G Karte, als auch über die 1G Karte direkt auf den Hyper-V Host, habe ich wieder vollen Durchsatz.
Mir scheinen die NIC Treiber OK zu sein. Es scheint mir als gäbe es massive Probleme zwischen den VM's kleiner 2019 und dem virtual Switch.
Wir haben jetzt angefangen und migrieren zurück auf 2012R2 um die Firma am laufen zu halten.
Testweise haben wir das Oracle System und einen Fileserver auf einen 2012R2 Hyper-V zu schieben. Ebenfalls mit den 10G Karten: Voller Durchsatz. Die Maschinen laufen rund.
Matt
Ich möchte hier gerne Einsteigen und unsere Erfahrung teilen:
System: Fujitsu 2540M5 mit 2x X710 10G Karten.
Hyper-V Rolle installiert. Eine 10G Karte als Taggen Uplink für die VM's.
Wir haben angefangen VMs von einem 2012R2 zu migrieren. Das Ganze lief 2 Wochen einwandfrei.
Vor einigen Tagen fingen die Performance Probleme der VMs an:
Datendurchsatz meist unter 22MB/s - oftmals um die 3MB/s. Teilweise lassen sich Dateien nicht öffnen, oder Verbindungen zu einer Oracle DB brechen ab.
Was ich beobachten konnte: Das Kopieren einer ISO Datei mit 1GB hat auf die VM's (2008, 2008R2 und 2012R2) einen Durchsatz von 3MB/s.
2019er VM's bringen allerdings den vollen Durchsatz!
Wir haben dann die internen RJ45 als virtual Switch konfiguriert. Es handelt sich hier um X722 Karten.
Hier zeigt sich exakt das selbe Verhalten.
Kopiere ich nun aber über die 10G Karte, als auch über die 1G Karte direkt auf den Hyper-V Host, habe ich wieder vollen Durchsatz.
Mir scheinen die NIC Treiber OK zu sein. Es scheint mir als gäbe es massive Probleme zwischen den VM's kleiner 2019 und dem virtual Switch.
Wir haben jetzt angefangen und migrieren zurück auf 2012R2 um die Firma am laufen zu halten.
Testweise haben wir das Oracle System und einen Fileserver auf einen 2012R2 Hyper-V zu schieben. Ebenfalls mit den 10G Karten: Voller Durchsatz. Die Maschinen laufen rund.
Matt
Moin Matt,
hast du auf dem 2019er alle MS-Updates installiert?
Falls WSUS vorhanden, so bitten den HV umkonfigurieren, dass dieser die Updates direkt aus dem Internet zieht.
Grüsse von einem der Seeen in Mecklenburg
Alex
hast du auf dem 2019er alle MS-Updates installiert?
Falls WSUS vorhanden, so bitten den HV umkonfigurieren, dass dieser die Updates direkt aus dem Internet zieht.
Grüsse von einem der Seeen in Mecklenburg
Alex
!!! Heureka !!!
Moin Leidensgenossen,
habe das Problem gefunden und auch gleich gelöst, kein Witz.
Nun zur ganzen Geschichte.
Wir haben die letzten Monate diverse HV Systeme ohne Probleme von 2012R2 und 2016 auf 2019 umgestellt. Alle Upgrades sind ohne Probleme verlaufen, bis auf das Letzte.
Bei der letzten Umstellung hatten wir im Anschluss wieder massiv mit Performanceproblemen zu kämpfen. Zurückgerudert sind wir nicht, ich habe kurzerhand drei I350 Adapter aus dem Lager geholt und die drei HVs damit bestückt und schon konnte der Kunde auch mit 2019 ohne nennenswerte Einbussen weiter arbeiten. Keine Sorge das ist jetzt nicht die Lösung.
Nun begann eine längere Suchaktion. Ich verglich akribisch die Einstellungen der NICs und konnte absolut nichts finden, was das Problem erklären würde. Diverse Konfigurationen wurden ausprobiert, mal mit, mal ohne VMQ, SR-IOV, RSS, RSC & Co. KG. Alle Versuche das Problem über die Erweiterten Einstellungen der NICs zu lösen, brachten entweder keine Besserung oder verschlimmbesserten die Lage.
Das Licht ging mir auf, als ich letztes Wochenende mal wieder exzessiv getestet habe.
Ich verschob auf einen Kundensystem alle für eine bestimmte Applikation relevanten Server auf denselben HV incl. Terminalserver. Dann stellte ich alle VM-Netzwerkadapter vom dem funktionierenden vSwitch mit 1G Uplinks (vSwitch1G) auf den vSwitch mit den 10G Uplinks (vSwitch10G) um, und sofort brach die Applikationsperformace mehr als nur spürbar ein.
Moment, dachte ich mir, das kann doch jetzt doch gar nicht sein. Die gesamte Kommunikation läuft nun nur noch über den vSwitch der von der Host-CPU gehandelt wird, da haben die NICs doch noch gar nichts mit dem Traffic zu tun.
Schnell PowerShell geöffnet und die Konfig des vSwitches abgefragt.
Get-VMSwitch -Name „NAME_VSWITCH“ | format-list
Und dann dasselbe Spielchen auf ein paar anderen HV 2019er Kundensystem, wo uns keine Performanceprobleme bekannt sind und schon war das Übel ersichtlich. Der vSwitch wurde an ein paar Stellen, mit absolut falschen Parametern generiert.
Ich habe zur besseren Übersicht die Werte in eine Tabelle reingeklopft.
Ich sage nur "BandwidthReservationMode"
Wer mehr wissen möchte, einfach Google mit folgender Anfrage quälen "BandwidthReservationMode bug"
Gibt es anscheinend schon seit 2012, aber warum das jetzt ausgerechnet mit den INTEL >= X540er und HV 2019er vermehrt auftritt, habe ich noch nicht raus gefunden.
Nun war die Lösung nur noch einen Katzensprung entfernt.
Ich habe den vorherigen fehlerhaften vSwitch gelöscht und per PowerShell mit dem folgenden Befehl einen neuen angelegt.
New-VMSwitch -Name " NAME_VSWITCH " -MinimumBandwidthMode Absolute -NetAdapterName "NIC 1.1 - PROD 10G" -AllowManagementOS $false
Falls jemand Multilinks benutzt, dann muss er diese nicht mehr vorher im OS vorkonfigurieren, das klappt ab HV 2016 direkt auf dem vSwitch.
Dazu die folgende beiden Befehle ausführen.
New-VMSwitch -Name "NAME_VSWITCH" -MinimumBandwidthMode Absolute -NetAdapterName
"NAME_NIC_1", "NAME_NIC_2" -EnableEmbeddedTeaming $true -AllowManagementOS $false
Set-VMSwitchTeam -Name "DESIG-PROD-10G-BIUL" -LoadBalancingAlgorithm Dynamic
Und schon war der Fisch geputzt. 😊
Habe heute Nachmittag die Bestätigung von Kunden bekommen, dass die Änderungen gefruchtet haben. Es sind seit der Umstellung keine Performanceeinbussen auf dem vSwitch mit den X722er und X540er mehr aufgetreten. 🥳
Der Vollständigkeit halber, die jetzige Konfig läuft ohne VMQ, SR-IOV, RSS, wir werden die genannten Features nun kontrolliert nach und nach aktivieren und schauen was passiert.
Ich halte diesbezüglich auf dem Laufenden.
Ich bin mir aber 100% sicher, dass das Problem an dem vSwitch lag. Wir haben noch ein weiteres 2019er System, welches Ende 2018 mit X722er ausgeliefert wurde und im Nachgang mit 1G (I350) nachgerüstet wurde, da die Performance nicht passte. Auch dort ist der vSwitch vom OS bei der Konfiguration per GUI falsch generiert worden.
Grüsse aus BaWü
Alex
Moin Leidensgenossen,
habe das Problem gefunden und auch gleich gelöst, kein Witz.
Nun zur ganzen Geschichte.
Wir haben die letzten Monate diverse HV Systeme ohne Probleme von 2012R2 und 2016 auf 2019 umgestellt. Alle Upgrades sind ohne Probleme verlaufen, bis auf das Letzte.
Bei der letzten Umstellung hatten wir im Anschluss wieder massiv mit Performanceproblemen zu kämpfen. Zurückgerudert sind wir nicht, ich habe kurzerhand drei I350 Adapter aus dem Lager geholt und die drei HVs damit bestückt und schon konnte der Kunde auch mit 2019 ohne nennenswerte Einbussen weiter arbeiten. Keine Sorge das ist jetzt nicht die Lösung.
Nun begann eine längere Suchaktion. Ich verglich akribisch die Einstellungen der NICs und konnte absolut nichts finden, was das Problem erklären würde. Diverse Konfigurationen wurden ausprobiert, mal mit, mal ohne VMQ, SR-IOV, RSS, RSC & Co. KG. Alle Versuche das Problem über die Erweiterten Einstellungen der NICs zu lösen, brachten entweder keine Besserung oder verschlimmbesserten die Lage.
Das Licht ging mir auf, als ich letztes Wochenende mal wieder exzessiv getestet habe.
Ich verschob auf einen Kundensystem alle für eine bestimmte Applikation relevanten Server auf denselben HV incl. Terminalserver. Dann stellte ich alle VM-Netzwerkadapter vom dem funktionierenden vSwitch mit 1G Uplinks (vSwitch1G) auf den vSwitch mit den 10G Uplinks (vSwitch10G) um, und sofort brach die Applikationsperformace mehr als nur spürbar ein.
Moment, dachte ich mir, das kann doch jetzt doch gar nicht sein. Die gesamte Kommunikation läuft nun nur noch über den vSwitch der von der Host-CPU gehandelt wird, da haben die NICs doch noch gar nichts mit dem Traffic zu tun.
Schnell PowerShell geöffnet und die Konfig des vSwitches abgefragt.
Get-VMSwitch -Name „NAME_VSWITCH“ | format-list
Und dann dasselbe Spielchen auf ein paar anderen HV 2019er Kundensystem, wo uns keine Performanceprobleme bekannt sind und schon war das Übel ersichtlich. Der vSwitch wurde an ein paar Stellen, mit absolut falschen Parametern generiert.
Ich habe zur besseren Übersicht die Werte in eine Tabelle reingeklopft.
Ich sage nur "BandwidthReservationMode"
Wer mehr wissen möchte, einfach Google mit folgender Anfrage quälen "BandwidthReservationMode bug"
Gibt es anscheinend schon seit 2012, aber warum das jetzt ausgerechnet mit den INTEL >= X540er und HV 2019er vermehrt auftritt, habe ich noch nicht raus gefunden.
Nun war die Lösung nur noch einen Katzensprung entfernt.
Ich habe den vorherigen fehlerhaften vSwitch gelöscht und per PowerShell mit dem folgenden Befehl einen neuen angelegt.
New-VMSwitch -Name " NAME_VSWITCH " -MinimumBandwidthMode Absolute -NetAdapterName "NIC 1.1 - PROD 10G" -AllowManagementOS $false
Falls jemand Multilinks benutzt, dann muss er diese nicht mehr vorher im OS vorkonfigurieren, das klappt ab HV 2016 direkt auf dem vSwitch.
Dazu die folgende beiden Befehle ausführen.
New-VMSwitch -Name "NAME_VSWITCH" -MinimumBandwidthMode Absolute -NetAdapterName
"NAME_NIC_1", "NAME_NIC_2" -EnableEmbeddedTeaming $true -AllowManagementOS $false
Set-VMSwitchTeam -Name "DESIG-PROD-10G-BIUL" -LoadBalancingAlgorithm Dynamic
Und schon war der Fisch geputzt. 😊
Habe heute Nachmittag die Bestätigung von Kunden bekommen, dass die Änderungen gefruchtet haben. Es sind seit der Umstellung keine Performanceeinbussen auf dem vSwitch mit den X722er und X540er mehr aufgetreten. 🥳
Der Vollständigkeit halber, die jetzige Konfig läuft ohne VMQ, SR-IOV, RSS, wir werden die genannten Features nun kontrolliert nach und nach aktivieren und schauen was passiert.
Ich halte diesbezüglich auf dem Laufenden.
Ich bin mir aber 100% sicher, dass das Problem an dem vSwitch lag. Wir haben noch ein weiteres 2019er System, welches Ende 2018 mit X722er ausgeliefert wurde und im Nachgang mit 1G (I350) nachgerüstet wurde, da die Performance nicht passte. Auch dort ist der vSwitch vom OS bei der Konfiguration per GUI falsch generiert worden.
Grüsse aus BaWü
Alex
1
Hallo,
vielen Dank für deine Ausführliche Antwort.
Habe bei mir dasselbe Problem, die vSwitch Einstellungen sind allerdings korrekt.
3x HyperV Host(s), welche von 2016 auf 2019 upgegradet worden sind.
Geschwindigkeit bricht bei mir extrem bei kleineren Dateien ein. Einzelne große Dateien stellen kein Problem dar.
Weiße ich der VM die 1GB Nic zu, ist die Geschwindigkeit wie gewünscht...
Bei mir sind allerdings folgende 10GB NICs verbaut:
1x Intel 82599 10GB
1x Intel X520
1x Intel X710
VMQ = deaktiviert
Falls es noch weitere Ideen gibt, bitte ich darum
Danke
vielen Dank für deine Ausführliche Antwort.
Habe bei mir dasselbe Problem, die vSwitch Einstellungen sind allerdings korrekt.
3x HyperV Host(s), welche von 2016 auf 2019 upgegradet worden sind.
Geschwindigkeit bricht bei mir extrem bei kleineren Dateien ein. Einzelne große Dateien stellen kein Problem dar.
Weiße ich der VM die 1GB Nic zu, ist die Geschwindigkeit wie gewünscht...
Bei mir sind allerdings folgende 10GB NICs verbaut:
1x Intel 82599 10GB
1x Intel X520
1x Intel X710
VMQ = deaktiviert
Falls es noch weitere Ideen gibt, bitte ich darum
Danke
Moin Mastersp,
"Weiße ich der VM die 1GB Nic zu, ist die Geschwindigkeit wie gewünscht..."
Wie meinst du das genau?
Laut deinen Angaben sind im Server nur 10G NICs verbaut?
Hast du eine der NICs auf 1G "gedrosselt"?
Grüsse aus Murrhardt
Alex
"Weiße ich der VM die 1GB Nic zu, ist die Geschwindigkeit wie gewünscht..."
Wie meinst du das genau?
Laut deinen Angaben sind im Server nur 10G NICs verbaut?
Hast du eine der NICs auf 1G "gedrosselt"?
Grüsse aus Murrhardt
Alex
Sorry falsch formuliert.
Die Server haben zusätzlich zu den 10GB NICs jeweils Broadcom GB (onboard).
Meine VMs haben nun einen vSwitch via den 1GB Karten, hier gibts keine Performance-Probleme.
Sobald ich die 10GB vSwitch verwende bricht die Geschwindigkeit ein.
Kann man sehr gut mit Kopiervorgängen testen.
liebe Grüße
Die Server haben zusätzlich zu den 10GB NICs jeweils Broadcom GB (onboard).
Meine VMs haben nun einen vSwitch via den 1GB Karten, hier gibts keine Performance-Probleme.
Sobald ich die 10GB vSwitch verwende bricht die Geschwindigkeit ein.
Kann man sehr gut mit Kopiervorgängen testen.
liebe Grüße
Moin MasterSP,
ich habe die Vermutung, dass es entweder am RSS oder am RSC liegt, hatte Zuletzt aber absolut keine Zeit das Thema weiter zu verfolgen.
---
In der aktuellen Readme des 24.2 habe ich die folgenden interessanten Einträge gefunden.
Unexpected CPU utilization
You may see one CPU reaching 90%-100% utilization if the RSS Load Balancing
Profile is set to NUMAScalingStatic. Setting the RSS Load Balancing Profile to
ClosestProcessor should correctly balance the CPU load. This issue affects
devices based on the Intel(R) Ethernet Controller X722 in systems running
Microsoft* Windows Server* 2019.
RSS Load Balancing Profile Advanced Setting
Setting the "RSS load balancing profile" Advanced Setting to "ClosestProcessor"
may significantly reduce CPU utilization. However, in some system
configurations (such as a system with more Ethernet ports than processor
cores), the "ClosestProcessor" setting may cause transmit and receive failures.
Changing the setting to "NUMAScalingStatic" will resolve the issue.
Multicast routing table is not automatically set up
The multicast routing table for the Intel(R) Ethernet Virtual Function 700
Series driver is not automatically set up and the virtual machine will not
receive multicast traffic. Manually adding the multicast routing will resolve
the issue.
Reduced or erratic receive performance
Intel(R) 7500 chipset-based systems may experience degraded receive
performance. Increasing receive descriptors to 1024 will resolve the issue.
Disabling C-states in the system BIOS will also resolve the issue.
CPU utilization higher than expected
Setting RSS Queues to a value greater than 4 is only advisable for large web
servers with several processors. Values greater than 4 may increase CPU
utilization to unacceptable levels and have other negative impacts on system
performance.
VLANs are not supported on VMQ enabled adapters and teams
If you create a VLAN on a VMQ enabled adapter, the VMQ setting will
automatically be set to disabled. The same will happen if you create a VLAN on
a team whose member adapters have VMQ enabled.
Reduced Large Send Offload performance
Large Send Offload (LSO) and IPSec Offload are not compatible. LSO is
automatically disabled when IPSec Offload is enabled. This may reduce the
performance of non-IPSec traffic. Confining all of your IPSec traffic to one
port and enabling IPSec Offload only on that port may mitigate this issue. On
Microsoft Windows 8.1 and Server 2012 and later, devices based on the 82576,
82599, and X540 controllers are not affected by this issue.
Network stack will not enable RSC
If Intel Data Center Bridging (DCB) is installed (FCoE, iSCSi, or both), the
network stack will not enable Receive Segment Coalescing (RSC)
---
werde mich die Tage wieder dran klemmen (müssen).
Grüsse aus Murrhardt
Alex
ich habe die Vermutung, dass es entweder am RSS oder am RSC liegt, hatte Zuletzt aber absolut keine Zeit das Thema weiter zu verfolgen.
---
In der aktuellen Readme des 24.2 habe ich die folgenden interessanten Einträge gefunden.
Unexpected CPU utilization
You may see one CPU reaching 90%-100% utilization if the RSS Load Balancing
Profile is set to NUMAScalingStatic. Setting the RSS Load Balancing Profile to
ClosestProcessor should correctly balance the CPU load. This issue affects
devices based on the Intel(R) Ethernet Controller X722 in systems running
Microsoft* Windows Server* 2019.
RSS Load Balancing Profile Advanced Setting
Setting the "RSS load balancing profile" Advanced Setting to "ClosestProcessor"
may significantly reduce CPU utilization. However, in some system
configurations (such as a system with more Ethernet ports than processor
cores), the "ClosestProcessor" setting may cause transmit and receive failures.
Changing the setting to "NUMAScalingStatic" will resolve the issue.
Multicast routing table is not automatically set up
The multicast routing table for the Intel(R) Ethernet Virtual Function 700
Series driver is not automatically set up and the virtual machine will not
receive multicast traffic. Manually adding the multicast routing will resolve
the issue.
Reduced or erratic receive performance
Intel(R) 7500 chipset-based systems may experience degraded receive
performance. Increasing receive descriptors to 1024 will resolve the issue.
Disabling C-states in the system BIOS will also resolve the issue.
CPU utilization higher than expected
Setting RSS Queues to a value greater than 4 is only advisable for large web
servers with several processors. Values greater than 4 may increase CPU
utilization to unacceptable levels and have other negative impacts on system
performance.
VLANs are not supported on VMQ enabled adapters and teams
If you create a VLAN on a VMQ enabled adapter, the VMQ setting will
automatically be set to disabled. The same will happen if you create a VLAN on
a team whose member adapters have VMQ enabled.
Reduced Large Send Offload performance
Large Send Offload (LSO) and IPSec Offload are not compatible. LSO is
automatically disabled when IPSec Offload is enabled. This may reduce the
performance of non-IPSec traffic. Confining all of your IPSec traffic to one
port and enabling IPSec Offload only on that port may mitigate this issue. On
Microsoft Windows 8.1 and Server 2012 and later, devices based on the 82576,
82599, and X540 controllers are not affected by this issue.
Network stack will not enable RSC
If Intel Data Center Bridging (DCB) is installed (FCoE, iSCSi, or both), the
network stack will not enable Receive Segment Coalescing (RSC)
---
werde mich die Tage wieder dran klemmen (müssen).
Grüsse aus Murrhardt
Alex
Hallo Leidensgenossen,
wir haben aktuell genau das beschriebene Problem bei einem Kunden.
Neuer Server Supermicro X11 mit onboard NIC X722, HyperV 2019 und VM 2019 ist total träge im Dateizugriff.
Durchsatz vom Server zum Client oft nur 3-4 Mbit/s. Besonders beim Zugriff auf Dateien im MB-Bereich spürbar.
Geschwindigkeit nimmt nach 5-10 Sekunden dann Fahrt auf (bei Dateien mit einigen GB). Dann voller Gbit-Speed (ca. 113 MB/Sek).
In Gegenrichtung (Client zum Server) scheinbar kein Problem.
Leider hat bei uns bisher keine der diskutierten Lösungsmöglichkeiten geholfen.
Wir haben die aktuellsten NIC-Treiber (Intel 24.3), vSwitch neu erstellt (BandwithReservation=Absolut), RSC deaktiviert, RSS deaktiviert, sämtliche IP-/TCP-Offloading-Optionen deaktiviert, VMQ deaktiviert, SR-IOV deaktiviert.
Zuletzt haben wir eine i350 NIC eingebaut und auch keine Änderung festgestellt.
Kabel getauscht, Switch getauscht.
Clients sind W10 1903 mit Realtek Gbit onboard.
Testweise habe ich auch in einem Client eine andere (Intel) Gbit-Karte eingebaut. Keine Änderung.
Auch am Client probeweise alle Offloadings und RSS deaktiviert.
Dann haben wir rein zufällig den Linkspeed eines Clients von 1000 auf 100 Mbit/s reduziert.
Damit sind die Verzögerungen plötzlich nicht mehr vorhanden. Kleine Dateien öffnen mit 100 Mbit um ein Vielfaches schneller als mit 1000 Mbit Link. Das Verhalten lässt sich reproduzieren: 1000 Mbit Link -> sofort wieder langsam.
Es liegt aber definitiv nicht an Netzwerkkabel oder -dose. Das wurde durchgemessen und ist einwandfrei.
Außerdem lief über dasselbe Kabel schon früher eine Gbit-Verbindung und der Zugriff auf den alten Server (2008) war schnell.
Nun Frage ich mich:
Was macht der Server 2019 anders wenn ein Client mit einem 100 Mbit Link zugreift?
Sind dann vielleicht irgendwelche erweiterten Features nicht aktiv?
Hat noch jemand eine Idee?
Ich bin sonst kurz davor einen Server 2016 aufzusetzen.
Gruß
Dennis
wir haben aktuell genau das beschriebene Problem bei einem Kunden.
Neuer Server Supermicro X11 mit onboard NIC X722, HyperV 2019 und VM 2019 ist total träge im Dateizugriff.
Durchsatz vom Server zum Client oft nur 3-4 Mbit/s. Besonders beim Zugriff auf Dateien im MB-Bereich spürbar.
Geschwindigkeit nimmt nach 5-10 Sekunden dann Fahrt auf (bei Dateien mit einigen GB). Dann voller Gbit-Speed (ca. 113 MB/Sek).
In Gegenrichtung (Client zum Server) scheinbar kein Problem.
Leider hat bei uns bisher keine der diskutierten Lösungsmöglichkeiten geholfen.
Wir haben die aktuellsten NIC-Treiber (Intel 24.3), vSwitch neu erstellt (BandwithReservation=Absolut), RSC deaktiviert, RSS deaktiviert, sämtliche IP-/TCP-Offloading-Optionen deaktiviert, VMQ deaktiviert, SR-IOV deaktiviert.
Zuletzt haben wir eine i350 NIC eingebaut und auch keine Änderung festgestellt.
Kabel getauscht, Switch getauscht.
Clients sind W10 1903 mit Realtek Gbit onboard.
Testweise habe ich auch in einem Client eine andere (Intel) Gbit-Karte eingebaut. Keine Änderung.
Auch am Client probeweise alle Offloadings und RSS deaktiviert.
Dann haben wir rein zufällig den Linkspeed eines Clients von 1000 auf 100 Mbit/s reduziert.
Damit sind die Verzögerungen plötzlich nicht mehr vorhanden. Kleine Dateien öffnen mit 100 Mbit um ein Vielfaches schneller als mit 1000 Mbit Link. Das Verhalten lässt sich reproduzieren: 1000 Mbit Link -> sofort wieder langsam.
Es liegt aber definitiv nicht an Netzwerkkabel oder -dose. Das wurde durchgemessen und ist einwandfrei.
Außerdem lief über dasselbe Kabel schon früher eine Gbit-Verbindung und der Zugriff auf den alten Server (2008) war schnell.
Nun Frage ich mich:
Was macht der Server 2019 anders wenn ein Client mit einem 100 Mbit Link zugreift?
Sind dann vielleicht irgendwelche erweiterten Features nicht aktiv?
Hat noch jemand eine Idee?
Ich bin sonst kurz davor einen Server 2016 aufzusetzen.
Gruß
Dennis
Moin Dennis,
"Zuletzt haben wir eine i350 NIC eingebaut und auch keine Änderung festgestellt."
Was meinst du damit genau?
Bei allen unseren bisherigen X722 2019er Problemkindern hat der Einbau einer i350er die Problematik behoben.
Gruss Alex
"Zuletzt haben wir eine i350 NIC eingebaut und auch keine Änderung festgestellt."
Was meinst du damit genau?
Bei allen unseren bisherigen X722 2019er Problemkindern hat der Einbau einer i350er die Problematik behoben.
Gruss Alex
Mit der i350-T2 ist es bei uns genauso langsam wie mit der X722.
Kein Unterschied: Geschwindigkeit von VM 2019 zu Clients weiterhin anfänglich nur 3-4 Mbit/s.
VM mit 2016 probeweise installiert: sofort volle Gigabit Geschwindigkeit ohne Verzögerungen.
Ich verstehe es nicht mehr.
Gruß Dennis
Kein Unterschied: Geschwindigkeit von VM 2019 zu Clients weiterhin anfänglich nur 3-4 Mbit/s.
VM mit 2016 probeweise installiert: sofort volle Gigabit Geschwindigkeit ohne Verzögerungen.
Ich verstehe es nicht mehr.
Gruß Dennis
Total verrückt:
Ich kann auch einen Unterschied durch den Linkspeed am Server feststellen.
i350 im HyperV 2019 mit 1000 Mbit Link:
VM 2019 -> Client = verzögerter Dateizugriff (3-4 Mbit/s)
VM 2016 -> Client = keine Verzögerung (sofort übliche Durchsatzraten)
gleicher Server, gleiche NIC, aber auf _100_ Mbit Link runtergedreht:
VM 2019 -> Client = keine Verzögerungen mehr (sofort Durchsatz 90 Mbit/s)
Aktuell laufen die Anwendungen auf der 2019er VM damit um ein Vielfaches schneller als zuvor mit dem 1000er Link.
Kann sich jemand einen Reim darauf machen?
Ich kann auch einen Unterschied durch den Linkspeed am Server feststellen.
i350 im HyperV 2019 mit 1000 Mbit Link:
VM 2019 -> Client = verzögerter Dateizugriff (3-4 Mbit/s)
VM 2016 -> Client = keine Verzögerung (sofort übliche Durchsatzraten)
gleicher Server, gleiche NIC, aber auf _100_ Mbit Link runtergedreht:
VM 2019 -> Client = keine Verzögerungen mehr (sofort Durchsatz 90 Mbit/s)
Aktuell laufen die Anwendungen auf der 2019er VM damit um ein Vielfaches schneller als zuvor mit dem 1000er Link.
Kann sich jemand einen Reim darauf machen?
Moin Dennis,
"Kann sich jemand einen Reim darauf machen?"
+-, das riecht für mich nach RSS oder RSC, beim Letzteren, hat MS beim 2019er besonders kräftig rumgefummelt.
Siehe auch
https://www.computerweekly.com/de/tipp/Windows-Server-2019-Diese-SDN-Fun ...
Gib mal in einer CMD auf dem HV den folgenden Befehl ein. 😉
„netsh interface tcp show global“
Der Mist ist ganz schön tief auf der TCP Ebene verankert.
In dem folgenden Artikel werden die meisten Optionen ganz gut beschrieben und passt auch auf den Hyper-V obwohl der Artikel ursprünglich für VMware geschrieben wurde.
https://www.flatbox.org/vmware-vmxnet3-performance-fuer-windows-server-2 ...
An den TCP Stack Parameter habe ich bisher aus Zeitmangel noch nicht rumgespielt.
Aber ich denke, dass hier der Hund begraben sein könnte. Die Optionen haben sich zwischen 2016er und 2019er auf jeden Fall verändert, es sind neue dazugekommen aber auch welche wieder verschwunden.
Jetzt muss ich aber weiterflitzen.
Wünsche allen eine angenehme und erfolgreiche Woche.
Grüsse aus BaWü
Alex
"Kann sich jemand einen Reim darauf machen?"
+-, das riecht für mich nach RSS oder RSC, beim Letzteren, hat MS beim 2019er besonders kräftig rumgefummelt.
Siehe auch
https://www.computerweekly.com/de/tipp/Windows-Server-2019-Diese-SDN-Fun ...
Gib mal in einer CMD auf dem HV den folgenden Befehl ein. 😉
„netsh interface tcp show global“
Der Mist ist ganz schön tief auf der TCP Ebene verankert.
In dem folgenden Artikel werden die meisten Optionen ganz gut beschrieben und passt auch auf den Hyper-V obwohl der Artikel ursprünglich für VMware geschrieben wurde.
https://www.flatbox.org/vmware-vmxnet3-performance-fuer-windows-server-2 ...
An den TCP Stack Parameter habe ich bisher aus Zeitmangel noch nicht rumgespielt.
Aber ich denke, dass hier der Hund begraben sein könnte. Die Optionen haben sich zwischen 2016er und 2019er auf jeden Fall verändert, es sind neue dazugekommen aber auch welche wieder verschwunden.
Jetzt muss ich aber weiterflitzen.
Wünsche allen eine angenehme und erfolgreiche Woche.
Grüsse aus BaWü
Alex
Hallo Alex,
Danke für den Ansatz.
Ich habe mir die TCP-Optionen der Reihe nach vorgenommen.
Sowohl auf dem HyperV als auch in der Test-VM 2019 letztlich alle deaktiviert.
Aber leider keine Besserung der Performance...
Irgendwas muss bei uns noch anders sein...
Gruß
Dennis
Danke für den Ansatz.
Ich habe mir die TCP-Optionen der Reihe nach vorgenommen.
Sowohl auf dem HyperV als auch in der Test-VM 2019 letztlich alle deaktiviert.
Aber leider keine Besserung der Performance...
Irgendwas muss bei uns noch anders sein...
Gruß
Dennis
Moin Dennis,
wir haben diverseste Kundensysteme mit 2019 und i350er ohne Probleme am Laufen.
Ich würde dir gerne das folgende Angebot unterbreiten.
Wir machen für nächste Woche einen Termin aus und gleichen dein i350 Problemkind per Teamviewer mit einem System von uns ab, wo es keine Probleme gibt.
???
Schreib mich bei Interesse einfach per Mail an.
alexander.fuchs"at"n-g-i-s.com
Grüsse aus Murrhardt
Alex
wir haben diverseste Kundensysteme mit 2019 und i350er ohne Probleme am Laufen.
Ich würde dir gerne das folgende Angebot unterbreiten.
Wir machen für nächste Woche einen Termin aus und gleichen dein i350 Problemkind per Teamviewer mit einem System von uns ab, wo es keine Probleme gibt.
???
Schreib mich bei Interesse einfach per Mail an.
alexander.fuchs"at"n-g-i-s.com
Grüsse aus Murrhardt
Alex
Moin Zusammen,
kleines Update zu unserem Problemchen, aber ich muss mich kurz fassen, hatte gestern schon 18 Stunden auf dem Tacho und heute sind es wieder nicht weniger ... 😩🥱
Aber zurück zum Thema, ich habe gestern zu 99,9% den waren Grund für das ganze Schlamassel gefunden.
Zusammenfassend, es liegt nicht an Intel, sondern an einer signifikanten Änderung des TCP-Stacks seitens Microsoft.
Stichworte: CongestionProvider, CUBIC ...
Mehr Details siehe auch ...
Server 2019 network performance
etwa in der Mitte, siehe 5 blaue Screenshots.
Nun habe ich auf die Kürze eine gute und eine schlechte Nachricht.
Die gute Nachricht zuerst:
Bei einem 2019er Server lässt sich das Problem sehr einfach beheben.
Einfach das folgende in PowerShell reinklopfen, 2019er Server durchbooten und schon ist die Netzwerkperformance genau so gut wie beim 2016er. 😀
Habe gestern das erste 2019er System von CUBIC auf CTCP zurückgestellt.
Das heutige Feedback des Kunden: Heute lief alles wieder genau so schnell wie vor der Umstellung auf 2019. 😊
Das zweite 2019er System bei einem anderen Kunden wird noch diese Woche umgestellt, bei aller Euphorie möchte ich dennoch vorsichtig vorgehen.
Bitte um weitere Unterstützung um den Lösungsansatz zu untermauern, danke.
Nun kommen ich zu der schlechten Nachricht.
Den Gleichen Bockmist hat Microsoft auch beim Windows 10 ab Version 1709 geschossen.
Dort lässt sich das Ganze stand jetzt jedoch nicht rückgängig machen. 😡
So nun muss ich aber dringend die Schaffe zählen gehen ...
Grüsse aus BaWü
Alex
kleines Update zu unserem Problemchen, aber ich muss mich kurz fassen, hatte gestern schon 18 Stunden auf dem Tacho und heute sind es wieder nicht weniger ... 😩🥱
Aber zurück zum Thema, ich habe gestern zu 99,9% den waren Grund für das ganze Schlamassel gefunden.
Zusammenfassend, es liegt nicht an Intel, sondern an einer signifikanten Änderung des TCP-Stacks seitens Microsoft.
Stichworte: CongestionProvider, CUBIC ...
Mehr Details siehe auch ...
Server 2019 network performance
etwa in der Mitte, siehe 5 blaue Screenshots.
Nun habe ich auf die Kürze eine gute und eine schlechte Nachricht.
Die gute Nachricht zuerst:
Bei einem 2019er Server lässt sich das Problem sehr einfach beheben.
Einfach das folgende in PowerShell reinklopfen, 2019er Server durchbooten und schon ist die Netzwerkperformance genau so gut wie beim 2016er. 😀
Set-NetTCPSetting -SettingName "InternetCustom" -CongestionProvider CTCP
Set-NetTCPSetting -SettingName "InternetCustom" -DelayedAckTimeoutMs 50
Set-NetTCPSetting -SettingName "InternetCustom" -ForceWS Disabled
Set-NetTCPSetting -SettingName "DatacenterCustom" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "DatacenterCustom" -CwndRestart True
Set-NetTCPSetting -SettingName "DatacenterCustom" -ForceWS Disabled
Set-NetTCPSetting -SettingName "Compat" -ForceWS Disabled
Set-NetTCPSetting -SettingName "Datacenter" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "Datacenter" -CwndRestart True
Set-NetTCPSetting -SettingName "Datacenter" -ForceWS Disabled
Set-NetTCPSetting -SettingName "Internet" -CongestionProvider CTCP
Set-NetTCPSetting -SettingName "InternetCustom" -DelayedAckTimeoutMs 50
Set-NetTCPSetting -SettingName "Internet" -ForceWS Disabled Habe gestern das erste 2019er System von CUBIC auf CTCP zurückgestellt.
Das heutige Feedback des Kunden: Heute lief alles wieder genau so schnell wie vor der Umstellung auf 2019. 😊
Das zweite 2019er System bei einem anderen Kunden wird noch diese Woche umgestellt, bei aller Euphorie möchte ich dennoch vorsichtig vorgehen.
Bitte um weitere Unterstützung um den Lösungsansatz zu untermauern, danke.
Nun kommen ich zu der schlechten Nachricht.
Den Gleichen Bockmist hat Microsoft auch beim Windows 10 ab Version 1709 geschossen.
Dort lässt sich das Ganze stand jetzt jedoch nicht rückgängig machen. 😡
So nun muss ich aber dringend die Schaffe zählen gehen ...
Grüsse aus BaWü
Alex
Servus Alex, muss man diese Befehle für jede VM einzeln setzen, oder muss das nur auf dem HyperV Host selber gemacht werden?
Moin Assassin,
das Skript kannst du auf JEDEM Server 2019 aufführen, die sind alle egal ob mit oder ohne Hyper-V mit CUBIC verseucht. 🤪
Gruss Alex
das Skript kannst du auf JEDEM Server 2019 aufführen, die sind alle egal ob mit oder ohne Hyper-V mit CUBIC verseucht. 🤪
Gruss Alex
Moin Zusammen,
bevor ich es vergesse, habe auch bei Windows 10 einen Weg gefunden den CUBIC Zahn zu ziehen. 😁
THE HOLLY WINDOWS 10 NO CUBIC SCRIPT
(mit Adminrechten ausführen)
Und der Vollständigkeit halber noch das retour Script
WINDOWS 10 CUBIC BACK SCRIPT 😱
(mit Adminrechten ausführen)
Würde mich über ein Feedback freuen.
Grüsse aus Sigmaringen
Alex
bevor ich es vergesse, habe auch bei Windows 10 einen Weg gefunden den CUBIC Zahn zu ziehen. 😁
THE HOLLY WINDOWS 10 NO CUBIC SCRIPT
(mit Adminrechten ausführen)
netsh int tcp set supplemental template=internet congestionprovider=CTCP
netsh int tcp set supplemental template=internetcustom congestionprovider=CTCP
netsh int tcp set supplemental template=Datacenter congestionprovider=DCTCP
netsh int tcp set supplemental template=Datacentercustom congestionprovider=DCTCPUnd der Vollständigkeit halber noch das retour Script
WINDOWS 10 CUBIC BACK SCRIPT 😱
(mit Adminrechten ausführen)
netsh int tcp set supplemental template=internet congestionprovider=CUBIC
netsh int tcp set supplemental template=internetcustom congestionprovider=CUBIC
netsh int tcp set supplemental template=Datacenter congestionprovider=CUBIC
netsh int tcp set supplemental template=Datacentercustom congestionprovider=CUBICWürde mich über ein Feedback freuen.
Grüsse aus Sigmaringen
Alex
Servus, ich nochmal :D
Du hast bei Spiceworks in deinem Script das hier mit drin:
#NATIVE2019, HV2019, VM2019
#netsh int tcp show global
netsh int tcp set global RSS=Disabled
netsh int tcp set global RSC=Disabled
bei RSC gehe ich ja noch mit, das ist die allgemeine Empfehlung von Intel das auszuschalten...aber RSS bei einer 10G Karte? Dann würde ja alles nur noch über eine CPU Core gehen und das ganze auf 4Gbs eindampfen (cpu limit) oder hat das nichts mit dem RSS was man im Karten-Treiber einstzellen kan, zutun?
Du hast bei Spiceworks in deinem Script das hier mit drin:
#NATIVE2019, HV2019, VM2019
#netsh int tcp show global
netsh int tcp set global RSS=Disabled
netsh int tcp set global RSC=Disabled
bei RSC gehe ich ja noch mit, das ist die allgemeine Empfehlung von Intel das auszuschalten...aber RSS bei einer 10G Karte? Dann würde ja alles nur noch über eine CPU Core gehen und das ganze auf 4Gbs eindampfen (cpu limit) oder hat das nichts mit dem RSS was man im Karten-Treiber einstzellen kan, zutun?
Moin Assassin,
sorry fürs Delay, war die letzten Wochen etwas Land unter.
Wir kommen gleich zur Sache, aber generell eines vorweg. Ja die ganzen Optimierungsfeatures alla RSC, RSS, SR-IOV, VMQ & Co. KG sollten laut der Theorie und vielleicht auch einigen Laborumgebungen eine bessere Performance bringen. Nur ist das mit der Theorie halt so eine Theorie und die Praxis ist eben die Praxis. In dieser bring der vorher erwähnte Mist, überwiegend nur Probleme mit sich, da so gut wie kein Normalsterblicher ein Labor betreibt. Die Meisten haben eher eine historisch gewachsene Umgebung.
So jetzt aber genug Philosophiepallaber ... 🤪
Ja, ich habe auch von dieser Einschränkung gehört, kann diese jedoch nicht ganz nachvollziehen.
Ich spiel das mal auf einem 2019er HV-Cluster eines unserer Kunden durch und verwende dazu einen der Clusterlinks, die über 10G laufen.
Dieses HV Cluster ist bereits mit allem optimiert was ich kenne, NO RSS, NO RSC, NO CUBIC, NO SR-IOV, VO VMQ, u.s.w. ...
Wie du siehst, kann ich den 10G Link auch ohne RSS und selbst mit einem "Singletask", fast zu 100% auslasten. 😉
---
Ich finde RSS generell nicht schlecht, jedoch ist vielen gar nicht bewusst, dass dieses gar nicht so einfach in Betrieb zu nehmen ist.
RSS ist zwar per default mittlerweile auf jeder NIC aktiviert, jedoch ist es mit den Standardeinstellungen, auf so gut wie jedem System mit mehr als einer NIC, störend bis unbrauchbar. Je mehr NICs man in einem System betreibt, umso granularer muss auch das RSS konfigurieren werden.
Die richtige Konfiguration hängt aber nicht nur von der Anzahl der NICs ab, sondern auch von der Anzahl, der auf diesem System verfügbaren CPU Kerne, der NUMA's, u.s.w.. Auf die Feinheiten kann ich aus Zeitmangel jetzt aber nicht eingehen, später vielleicht.
Unter dem Strich kann man sagen, umso grösser das System, umso komplexer ist auch die richtige RSS Konfiguration.
Hat man sich einmal die Mühe gemacht alles richtig einzustellen, so ist das keineswegs ein Grund zur langfristigen Freude.
Die Konfiguration fliegt schon mal gerne bei dem eine oder anderen MS oder NIC-Driver Update um die Ohren und man muss ales wieder neu einrichten. Kann da Bände dazu schreiben ... 😞
Ich habe bei aktiviertem und richtig konfiguriertem RSS, noch nie einen positiven Effekt beim Enduser erzielen können, das Gegenteilige jedoch schon oft genug. Bei deaktiviertem RSS hatte ich hingegen noch nie Stress und wie du oben siehst auch nicht wirklich einen Performancenachteil dadurch.
Grüsse aus BaWü
Alex
sorry fürs Delay, war die letzten Wochen etwas Land unter.
bei RSC gehe ich ja noch mit, das ist die allgemeine Empfehlung von Intel das auszuschalten...aber RSS bei einer 10G Karte? Dann würde ja alles nur noch über eine CPU Core gehen und das ganze auf 4Gbs eindampfen (cpu limit) oder hat das nichts mit dem RSS was man im Karten-Treiber einstzellen kan, zutun?
Wir kommen gleich zur Sache, aber generell eines vorweg. Ja die ganzen Optimierungsfeatures alla RSC, RSS, SR-IOV, VMQ & Co. KG sollten laut der Theorie und vielleicht auch einigen Laborumgebungen eine bessere Performance bringen. Nur ist das mit der Theorie halt so eine Theorie und die Praxis ist eben die Praxis. In dieser bring der vorher erwähnte Mist, überwiegend nur Probleme mit sich, da so gut wie kein Normalsterblicher ein Labor betreibt. Die Meisten haben eher eine historisch gewachsene Umgebung.
So jetzt aber genug Philosophiepallaber ... 🤪
Ja, ich habe auch von dieser Einschränkung gehört, kann diese jedoch nicht ganz nachvollziehen.
Ich spiel das mal auf einem 2019er HV-Cluster eines unserer Kunden durch und verwende dazu einen der Clusterlinks, die über 10G laufen.
Dieses HV Cluster ist bereits mit allem optimiert was ich kenne, NO RSS, NO RSC, NO CUBIC, NO SR-IOV, VO VMQ, u.s.w. ...
Wie du siehst, kann ich den 10G Link auch ohne RSS und selbst mit einem "Singletask", fast zu 100% auslasten. 😉
---
Ich finde RSS generell nicht schlecht, jedoch ist vielen gar nicht bewusst, dass dieses gar nicht so einfach in Betrieb zu nehmen ist.
RSS ist zwar per default mittlerweile auf jeder NIC aktiviert, jedoch ist es mit den Standardeinstellungen, auf so gut wie jedem System mit mehr als einer NIC, störend bis unbrauchbar. Je mehr NICs man in einem System betreibt, umso granularer muss auch das RSS konfigurieren werden.
Die richtige Konfiguration hängt aber nicht nur von der Anzahl der NICs ab, sondern auch von der Anzahl, der auf diesem System verfügbaren CPU Kerne, der NUMA's, u.s.w.. Auf die Feinheiten kann ich aus Zeitmangel jetzt aber nicht eingehen, später vielleicht.
Unter dem Strich kann man sagen, umso grösser das System, umso komplexer ist auch die richtige RSS Konfiguration.
Hat man sich einmal die Mühe gemacht alles richtig einzustellen, so ist das keineswegs ein Grund zur langfristigen Freude.
Die Konfiguration fliegt schon mal gerne bei dem eine oder anderen MS oder NIC-Driver Update um die Ohren und man muss ales wieder neu einrichten. Kann da Bände dazu schreiben ... 😞
Ich habe bei aktiviertem und richtig konfiguriertem RSS, noch nie einen positiven Effekt beim Enduser erzielen können, das Gegenteilige jedoch schon oft genug. Bei deaktiviertem RSS hatte ich hingegen noch nie Stress und wie du oben siehst auch nicht wirklich einen Performancenachteil dadurch.
Grüsse aus BaWü
Alex
Welche NIC hattest du da aber im einsatz? eventuell eine mit RDMA /iWARP technik?
Wir haben hier ein paar Intel X550-T2 10G karten, die haben kein iWARP...wenn ich da RSS deaktiviere, läuft der gesammte Trafic über einen Kern der beiden 16 Core CPUs, und das capt bei 400MB/s.
RSS arbeitet richtig bei mir, da ich es - wie du schon sagtest - konfiguriert habe, also jeden adapter der über RSS arbeitet entsprechende Cores zugeordnet habe, dem nächsten adapter auch Cores aber andere,...
Wie gesagt, ich denke bei einer 10G karte sollte man das RSS nicht deaktivieren, aber ja, es sollte konfiguriert werden. Eigentlich sollte Server2019 das automatisch und dynamisch machen, also die Cores zuordnen...naja
Wenn die karte aber RDMA hat, und die Server worauf man kopiert oder wovon man was zieht ebenfalls, dann kann man RSS deaktivieren...
Wir haben hier ein paar Intel X550-T2 10G karten, die haben kein iWARP...wenn ich da RSS deaktiviere, läuft der gesammte Trafic über einen Kern der beiden 16 Core CPUs, und das capt bei 400MB/s.
RSS arbeitet richtig bei mir, da ich es - wie du schon sagtest - konfiguriert habe, also jeden adapter der über RSS arbeitet entsprechende Cores zugeordnet habe, dem nächsten adapter auch Cores aber andere,...
Wie gesagt, ich denke bei einer 10G karte sollte man das RSS nicht deaktivieren, aber ja, es sollte konfiguriert werden. Eigentlich sollte Server2019 das automatisch und dynamisch machen, also die Cores zuordnen...naja
Wenn die karte aber RDMA hat, und die Server worauf man kopiert oder wovon man was zieht ebenfalls, dann kann man RSS deaktivieren...
Moin Assassin,
Ohne jetzt nachgeschaut zu haben, es sind glaube ich 4x2xX722. RDMA ist deaktiviert.
🤔, bei dem letzten System an dem ich das getestet habe, konnte ich mich nicht so richtig austoben, weil ich nur ein relativ kurzes Wartungsfenster hatte und dieses eigentlich nicht für Performancetests vorgesehen war.
Wir assemblieren in 1-2 Wochen ein neues, sehr potentes HV-Cluster (4 Nodes, je 2 x Xeon Gold 6254 & 1TB RAM & 4x10G).
Sobald dieses fertig ist, werde ich das Thema RSS mit diesem penibelst durchtesten und berichten.
das verstehen und machen nur wenige, 👍👍👍, Kompliment und Anerkennung.
---
Generell ist mir der Maximaldurchsatz aber nicht ganz so wichtig wie eine konstant niedrige Latenz, davon haben die User meistens mehr als vom Durchsatz.
Gruss Alex
Welche NIC hattest du da aber im einsatz? eventuell eine mit RDMA /iWARP technik?
Ohne jetzt nachgeschaut zu haben, es sind glaube ich 4x2xX722. RDMA ist deaktiviert.
Wir haben hier ein paar Intel X550-T2 10G karten, die haben kein iWARP...wenn ich da RSS deaktiviere, läuft der gesammte Trafic über einen Kern der beiden 16 Core CPUs, und das capt bei 400MB/s.
🤔, bei dem letzten System an dem ich das getestet habe, konnte ich mich nicht so richtig austoben, weil ich nur ein relativ kurzes Wartungsfenster hatte und dieses eigentlich nicht für Performancetests vorgesehen war.
Wir assemblieren in 1-2 Wochen ein neues, sehr potentes HV-Cluster (4 Nodes, je 2 x Xeon Gold 6254 & 1TB RAM & 4x10G).
Sobald dieses fertig ist, werde ich das Thema RSS mit diesem penibelst durchtesten und berichten.
RSS arbeitet richtig bei mir, da ich es - wie du schon sagtest - konfiguriert habe, also jeden adapter der über RSS arbeitet entsprechende Cores zugeordnet habe, dem nächsten adapter auch Cores aber andere,...
das verstehen und machen nur wenige, 👍👍👍, Kompliment und Anerkennung.
---
Generell ist mir der Maximaldurchsatz aber nicht ganz so wichtig wie eine konstant niedrige Latenz, davon haben die User meistens mehr als vom Durchsatz.
Gruss Alex
Ich bevorzuge beides :D
wegen der RSS und VMQ einstellung habe ich mir das hier erabeitet :
Set-NetAdapterVmq -Name "10G LAN Slot 03 Port 1 - VM NicTeam" -BaseProcessorNumber 2 -MaxProcessors 4 -MaxProcessorNumber 8 -NumaNode 0
Set-NetAdapterVmq -Name "10G LAN Slot 07 Port 1 - VM NicTeam" -BaseProcessorNumber 34 -MaxProcessors 4 -MaxProcessorNumber 40 -NumaNode 1
Set-NetAdapterVmq -Name "Onboard LAN Port 1 - andere Netze NicTeam" -BaseProcessorNumber 18 -MaxProcessors 1 -MaxProcessorNumber 18 -NumaNode 0
Set-NetAdapterVmq -Name "Onboard LAN Port 2 - andere Netze NicTeam" -BaseProcessorNumber 20 -MaxProcessors 1 -MaxProcessorNumber 20 -NumaNode 0
Set-NetAdapterRss -Name "10G LAN Slot 03 Port 2 - LiveMigration1 + FE" -BaseProcessorNumber 10 -MaxProcessors 4 -MaxProcessorNumber 16 -NumaNode 0
Set-NetAdapterRss -Name "10G LAN Slot 07 Port 2 - LiveMigration2 + FE" -BaseProcessorNumber 42 -MaxProcessors 4 -MaxProcessorNumber 48 -NumaNode 1
Set-NetAdapterRss -Name "Onboard QuadLAN Port 1 - Management NicTeam" -BaseProcessorNumber 22 -MaxProcessors 1 -MaxProcessorNumber 22 -NumaNode 0
Set-NetAdapterRss -Name "Onboard QuadLAN Port 2 - Backup NicTeam" -BaseProcessorNumber 24 -MaxProcessors 1 -MaxProcessorNumber 24 -NumaNode 0
Set-NetAdapterRss -Name "Onboard QuadLAN Port 3 - Cluster Communication" -BaseProcessorNumber 26 -MaxProcessors 1 -MaxProcessorNumber 26 -NumaNode 0
Set-NetAdapterRss -Name "Onboard QuadLAN Port 4 - Management NicTeam" -BaseProcessorNumber 28 -MaxProcessors 1 -MaxProcessorNumber 28 -NumaNode 0
Disable-NetAdapterRsc "Onboard QuadLAN Port 2 - Backup Netz" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard QuadLAN Port 1 - Management NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard QuadLAN Port 4 - Management NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard QuadLAN Port 3 - Cluster Communication" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 03 Port 1 - VM NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 07 Port 2 - LiveMigration2 + FE" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 07 Port 1 - VM NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 03 Port 2 - LiveMigration1 + FE" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard LAN Port 1 - andere Netze NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard LAN Port 2 - andere Netze NicTeam" -IPv4 -IPv6
Set-VMSwitch -Name "VM NicTeam (extern)" -EnableSoftwareRsc $false
Set-VMSwitch -Name "andere Netze (extern)" -EnableSoftwareRsc $false
das RSC zu deaktivieren, wird ja von Intel empfohlen wenn man VMQ nutzt (also das RSS für VMs sozusagen)
quelle: https://downloadmirror.intel.com/28396/eng/readme.txt
erster punkt bei Known Issues
Die wenigstens scheinen aber zwei 10G Ports zu Teamen für um den Potenten vSwitch dann an die VMs weiterzugeben...aber warum? Ich meine, unser Cluster hat 18 VMs im einsatz, ich kann mir nicht vorstellen, das alle VMs nur mit einer einzelnen Netzwerkkarte mit dem gesammten Netzwerk agieren sollen. Loadbalancing ist da schon nicht schlecht denke ich. Klar wird da nicht ständig mit 10G daten umhergeschaufelt - wobei das manchmal schon vorkommt, da einige Poweruser die große zeichnungen haben oder Videos - auch mit 10G angebunden sind am 10G Switch.
wegen der RSS und VMQ einstellung habe ich mir das hier erabeitet :
Set-NetAdapterVmq -Name "10G LAN Slot 03 Port 1 - VM NicTeam" -BaseProcessorNumber 2 -MaxProcessors 4 -MaxProcessorNumber 8 -NumaNode 0
Set-NetAdapterVmq -Name "10G LAN Slot 07 Port 1 - VM NicTeam" -BaseProcessorNumber 34 -MaxProcessors 4 -MaxProcessorNumber 40 -NumaNode 1
Set-NetAdapterVmq -Name "Onboard LAN Port 1 - andere Netze NicTeam" -BaseProcessorNumber 18 -MaxProcessors 1 -MaxProcessorNumber 18 -NumaNode 0
Set-NetAdapterVmq -Name "Onboard LAN Port 2 - andere Netze NicTeam" -BaseProcessorNumber 20 -MaxProcessors 1 -MaxProcessorNumber 20 -NumaNode 0
Set-NetAdapterRss -Name "10G LAN Slot 03 Port 2 - LiveMigration1 + FE" -BaseProcessorNumber 10 -MaxProcessors 4 -MaxProcessorNumber 16 -NumaNode 0
Set-NetAdapterRss -Name "10G LAN Slot 07 Port 2 - LiveMigration2 + FE" -BaseProcessorNumber 42 -MaxProcessors 4 -MaxProcessorNumber 48 -NumaNode 1
Set-NetAdapterRss -Name "Onboard QuadLAN Port 1 - Management NicTeam" -BaseProcessorNumber 22 -MaxProcessors 1 -MaxProcessorNumber 22 -NumaNode 0
Set-NetAdapterRss -Name "Onboard QuadLAN Port 2 - Backup NicTeam" -BaseProcessorNumber 24 -MaxProcessors 1 -MaxProcessorNumber 24 -NumaNode 0
Set-NetAdapterRss -Name "Onboard QuadLAN Port 3 - Cluster Communication" -BaseProcessorNumber 26 -MaxProcessors 1 -MaxProcessorNumber 26 -NumaNode 0
Set-NetAdapterRss -Name "Onboard QuadLAN Port 4 - Management NicTeam" -BaseProcessorNumber 28 -MaxProcessors 1 -MaxProcessorNumber 28 -NumaNode 0
Disable-NetAdapterRsc "Onboard QuadLAN Port 2 - Backup Netz" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard QuadLAN Port 1 - Management NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard QuadLAN Port 4 - Management NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard QuadLAN Port 3 - Cluster Communication" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 03 Port 1 - VM NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 07 Port 2 - LiveMigration2 + FE" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 07 Port 1 - VM NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 03 Port 2 - LiveMigration1 + FE" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard LAN Port 1 - andere Netze NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard LAN Port 2 - andere Netze NicTeam" -IPv4 -IPv6
Set-VMSwitch -Name "VM NicTeam (extern)" -EnableSoftwareRsc $false
Set-VMSwitch -Name "andere Netze (extern)" -EnableSoftwareRsc $false
das RSC zu deaktivieren, wird ja von Intel empfohlen wenn man VMQ nutzt (also das RSS für VMs sozusagen)
quelle: https://downloadmirror.intel.com/28396/eng/readme.txt
erster punkt bei Known Issues
Die wenigstens scheinen aber zwei 10G Ports zu Teamen für um den Potenten vSwitch dann an die VMs weiterzugeben...aber warum? Ich meine, unser Cluster hat 18 VMs im einsatz, ich kann mir nicht vorstellen, das alle VMs nur mit einer einzelnen Netzwerkkarte mit dem gesammten Netzwerk agieren sollen. Loadbalancing ist da schon nicht schlecht denke ich. Klar wird da nicht ständig mit 10G daten umhergeschaufelt - wobei das manchmal schon vorkommt, da einige Poweruser die große zeichnungen haben oder Videos - auch mit 10G angebunden sind am 10G Switch.
1
Moin Assassin,
dein Script ist auch sehr interessant, vielen Dank dafür.
Gute Frage ...
🙃
Gruss Alex
dein Script ist auch sehr interessant, vielen Dank dafür.
Die wenigstens scheinen aber zwei 10G Ports zu Teamen für um den Potenten vSwitch dann an die VMs weiterzugeben...aber warum?
Gute Frage ...
🙃
Gruss Alex
so lob ich mir das, kann nie schnell genug sein :D
Was hälst du von SET Teaming im vergleich zum LBFO Teaming? Wird ja hier und da empfohlen das Team als SET einzurichten über die Powershell...ich vermisse da aber die LACP möglichkeit damit auch eingehend ein loadbalancing möglich ist...
Was hälst du von SET Teaming im vergleich zum LBFO Teaming? Wird ja hier und da empfohlen das Team als SET einzurichten über die Powershell...ich vermisse da aber die LACP möglichkeit damit auch eingehend ein loadbalancing möglich ist...
Moin Assassin,
ist grundsätzlich sehr interessant, habe mich aber in der Tiefe noch nicht zu sehr damit beschäftigt.
Ich habe vor ein paar Monaten, bei einem der Systeme die von dem Netzwerk-Performanceproblem betroffen waren, mal das Teaming testweise auf SET umgestellt, jedoch keinerlei Veränderung damit erzielt.
Wenn ich die Materie auch nur halbwegs richtig verstanden habe, dann ist das durchaus möglich.
Du musst dafür aber den LoadBalancer des SET's auf "Dynamic" stellen.
Aber wie gesagt, so tief stecke ich da noch nicht in der Materie.
Die genaue Erforschung dieser, steht auf der ToDo Liste beim nächsten System drauf. 😉
Grüsse aus BaWü
Alex
Was hälst du von SET Teaming im vergleich zum LBFO Teaming?
ist grundsätzlich sehr interessant, habe mich aber in der Tiefe noch nicht zu sehr damit beschäftigt.
Ich habe vor ein paar Monaten, bei einem der Systeme die von dem Netzwerk-Performanceproblem betroffen waren, mal das Teaming testweise auf SET umgestellt, jedoch keinerlei Veränderung damit erzielt.
Wird ja hier und da empfohlen das Team als SET einzurichten über die Powershell...ich vermisse da aber die LACP möglichkeit damit auch eingehend ein loadbalancing möglich ist...
Wenn ich die Materie auch nur halbwegs richtig verstanden habe, dann ist das durchaus möglich.
Du musst dafür aber den LoadBalancer des SET's auf "Dynamic" stellen.
New-VMSwitch -Name "VSWITCH-PROD" -NetAdapterName "NIC-10G-01","NIC-10G-02" -EnableEmbeddedTeaming $true -AllowManagementOS $false
Set-VMSwitchTeam -Name "VSWITCH-PROD" -LoadBalancingAlgorithm Dynamic Aber wie gesagt, so tief stecke ich da noch nicht in der Materie.
Die genaue Erforschung dieser, steht auf der ToDo Liste beim nächsten System drauf. 😉
Grüsse aus BaWü
Alex
Moin Assassin,
habe dir ja versprochen das RSS Thema im Auge zu behalten und das habe ich nicht vergessen.
Ich bin gerade dabei eine Review für ein sehr flitziges Infortrend NAS vorzubereiten und bin dabei auf eine Kuriosität gestossen, die ich absolut nicht erklären kann.
https://community.spiceworks.com/topic/2265556-mystical-loadbalancing-by ...
Auch der 2nd Level des Herstellers ist bisher ratlos.
Noch ein paar wichtige Details zu der Workstation. In dieser sind zwei unterschiedliche 10G NIC’s verbaut. Onboard sitzt eine Aquantia NIC zusätzlich ist noch eine Intel X711-T4 verbaut.
OS: Windows 10 Enterprise 1909 (Build 18363.752)
Treiberversion Aquantia: 2.1.018.0
Treiberversion Intel: 25.0.0.0
Nun zu meinen bisherigen Feststellungen:
RSC:
Bei der Aquantia NIC lässt sich RSC wie gewohnt über GUI oder Power-Shell abschalten.
Wohingegen bei der Intel NIC unter Windows 10 von RSC weit und breit absolut nichts zu sehen ist.
Warum ist bei der Intel NIC unter Windows 10 kein RSC verfügbar?
Die Aquantia NIC unterstützt RSC und der TCP-Stack von Windows 10 per Default (leider 🤢) auch.
Beiden habe ich bei meinem jetzigen Aufbau sicherheitshalber nach der Installation sofort den RSC-Milchzahn 🙃 gezogen.
RSS:
Hier wird es noch lustiger oder trauriger, je nach Betrachtungswinkel.
Bei der Aquantia NIC kann ich noch am meisten einstellen.
Genau zwei Optionen RSS ein oder aus und die Queues.
Bei der Intel NIC gibt’s nur eine Einstellmöglichkeit …
RSS ein oder RSS aus, that‘s it. 😮
Ich kann das Limit mit den 400 MB/s auf der W10 Maschine übrigens 1A nachvollziehen.
Wenn ich RSS deaktiviere so kommen die NICs nicht über ~4GBit/s hinaus.
Ich werde die Tage den Test auf dem Server auf jeden Fall wiederholen, dort hatte ich trotz deaktiviertem RSS wie schon geschrieben keine derartige Limitierung feststellen können. 🤔
Auf jeden Fall läuft RSS auf meiner Workstation trotz der wenigen Einstellmöglichkeiten bisher absolut ohne Probleme.
Nun drängt sich mir die folgende Frage auf.
Warum funktioniert auf Windows 10 RSS mit fünf 10G NICs und nur wenigen Einstellmöglichkeiten per Default bestens, während dieses auf den Servern, selbst bei einer Bestückung mit nur einer 10G NIC nur durch komplexe Konfiguration von diversen Parametern möglich ist?
@ Microsoft, Moin, die geht hauptsächlich an Euch. 😉
Kleiner Tipp an dieser Stelle, Weniger ist manchmal eben doch Mehr.
Grüsse aus BaWü
Alex
Wir haben hier ein paar Intel X550-T2 10G karten, die haben kein iWARP...wenn ich da RSS deaktiviere, läuft der gesammte Trafic über einen Kern der beiden 16 Core CPUs, und das capt bei 400MB/s.
RSS arbeitet richtig bei mir, da ich es - wie du schon sagtest - konfiguriert habe, also jeden adapter der über RSS arbeitet entsprechende Cores zugeordnet habe, dem nächsten adapter auch Cores aber andere,...
RSS arbeitet richtig bei mir, da ich es - wie du schon sagtest - konfiguriert habe, also jeden adapter der über RSS arbeitet entsprechende Cores zugeordnet habe, dem nächsten adapter auch Cores aber andere,...
habe dir ja versprochen das RSS Thema im Auge zu behalten und das habe ich nicht vergessen.
Ich bin gerade dabei eine Review für ein sehr flitziges Infortrend NAS vorzubereiten und bin dabei auf eine Kuriosität gestossen, die ich absolut nicht erklären kann.
https://community.spiceworks.com/topic/2265556-mystical-loadbalancing-by ...
Auch der 2nd Level des Herstellers ist bisher ratlos.
Noch ein paar wichtige Details zu der Workstation. In dieser sind zwei unterschiedliche 10G NIC’s verbaut. Onboard sitzt eine Aquantia NIC zusätzlich ist noch eine Intel X711-T4 verbaut.
OS: Windows 10 Enterprise 1909 (Build 18363.752)
Treiberversion Aquantia: 2.1.018.0
Treiberversion Intel: 25.0.0.0
Nun zu meinen bisherigen Feststellungen:
RSC:
Bei der Aquantia NIC lässt sich RSC wie gewohnt über GUI oder Power-Shell abschalten.
Wohingegen bei der Intel NIC unter Windows 10 von RSC weit und breit absolut nichts zu sehen ist.
Warum ist bei der Intel NIC unter Windows 10 kein RSC verfügbar?
Die Aquantia NIC unterstützt RSC und der TCP-Stack von Windows 10 per Default (leider 🤢) auch.
Beiden habe ich bei meinem jetzigen Aufbau sicherheitshalber nach der Installation sofort den RSC-Milchzahn 🙃 gezogen.
RSS:
Hier wird es noch lustiger oder trauriger, je nach Betrachtungswinkel.
Bei der Aquantia NIC kann ich noch am meisten einstellen.
Genau zwei Optionen RSS ein oder aus und die Queues.
Bei der Intel NIC gibt’s nur eine Einstellmöglichkeit …
RSS ein oder RSS aus, that‘s it. 😮
Ich kann das Limit mit den 400 MB/s auf der W10 Maschine übrigens 1A nachvollziehen.
Wenn ich RSS deaktiviere so kommen die NICs nicht über ~4GBit/s hinaus.
Ich werde die Tage den Test auf dem Server auf jeden Fall wiederholen, dort hatte ich trotz deaktiviertem RSS wie schon geschrieben keine derartige Limitierung feststellen können. 🤔
Auf jeden Fall läuft RSS auf meiner Workstation trotz der wenigen Einstellmöglichkeiten bisher absolut ohne Probleme.
Nun drängt sich mir die folgende Frage auf.
Warum funktioniert auf Windows 10 RSS mit fünf 10G NICs und nur wenigen Einstellmöglichkeiten per Default bestens, während dieses auf den Servern, selbst bei einer Bestückung mit nur einer 10G NIC nur durch komplexe Konfiguration von diversen Parametern möglich ist?
@ Microsoft, Moin, die geht hauptsächlich an Euch. 😉
Kleiner Tipp an dieser Stelle, Weniger ist manchmal eben doch Mehr.
Grüsse aus BaWü
Alex
1
Ja ohne RSS wird man bei 400MB/s gecapt sozusagen - wegen der CPU. Warum es bei deinem Server trotzdem mit 10Gb/s übertragen hat kann ich dir nicht sagen - entweder RSS war nicht wirklich aus, oder es lief über SMB Multichannel was du ja jetzt auch entdeckt hast...doch auch das SMB3.0 Feature (Multichannel, gibts ein Windows 8) hat auch so seine tücken musste ich feststellen
https://www.mcseboard.de/topic/217424-smb-multichannel-nutze-nur-2-von-4 ...
egal wieschnell welche Netzwerkkarte angebunden ist, es werden immer die mit RDMA bevorzugt behandelt - da muss MS dringend nachbessern und vieleicht auch mal prüfen wieschnell die RDMA fähige karte angebunden ist, und ob es nicht doch andere NICs gibt, die deutlich schneller angebunden sind. Ich weiß zwar trotzdem noch nicht warum es bei mir diese einbrüche gibt, aber gut, das könnte was mit dem Raidcontroller zutun haben...auch wenn der in der zeit wo er schnell kopiert deutlich mehr daten transferriert hat, als in den Controller cache passen würde...
https://www.mcseboard.de/topic/217424-smb-multichannel-nutze-nur-2-von-4 ...
egal wieschnell welche Netzwerkkarte angebunden ist, es werden immer die mit RDMA bevorzugt behandelt - da muss MS dringend nachbessern und vieleicht auch mal prüfen wieschnell die RDMA fähige karte angebunden ist, und ob es nicht doch andere NICs gibt, die deutlich schneller angebunden sind. Ich weiß zwar trotzdem noch nicht warum es bei mir diese einbrüche gibt, aber gut, das könnte was mit dem Raidcontroller zutun haben...auch wenn der in der zeit wo er schnell kopiert deutlich mehr daten transferriert hat, als in den Controller cache passen würde...
Moin Assassin,
Dieses Fehlverhalten, das bevorzugen von langsameren NIC's unter Verwendung von SMB Multichannel kann ich aus zwei eigenen jüngsten Erfahrungen 1A bestätigen.
Deine Vermutung mit RDMA hingegen kann ich, glaube ich jedoch wiederlegen.
Meine letzten Erfahrungen mit dem Problem haben gezeigt, dass bei der Anwendung von SMB Multichannel, unabhängig vom RDMA, generell die langsamste verfügbare LAN Verbindung bevorzugt wird.
Ich habe zum Thema SMB Multichannel bei Spiceworks gerade auch die folgende Diskussion am Laufen.
https://community.spiceworks.com/topic/2265556-mystical-loadbalancing-by ...
Vor etwa zwei Wochen ist mir bei Testen etwas Komisches aufgefallen, das ich bisher nirgends thematisiert habe.
Aber vorher ein paar relevante technische Details.
Die verwendete Workstation hat 5 x 10G NICs, 1 x 1G und 1 x W-LAN.
Bei den ersten Tests waren nur die vier X710 direkt zu den vier 10G NICs der NAS verbunden, alle anderen NICs der Workstation waren offline, zusätzlich war die NAS mit einem der zwei 1G onboard NICs ebenfalls am Netz per Switch zwecks Managements angeschlossen.
In dieser Konstellation (an der Workstation nur die vier 10G NICs online) hat das SMB Multichannel wunderbar funktioniert. Ich konnte nur mit einem Stream alle vier 10G NICs fast vollständig auslasten, siehe Screenshot bei Spiceworks.
Dann musste ich mit der Workstation kurz ins Internet und habe dazu die 1G NIC ans Netz gehängt über welches auch die 1G NIC der NAS erreichbar war. Anschliessend habe ich vergessen die 1G NIC der Workstation wieder zu deaktivieren und wunderte mich bei den darauffolgenden Tests, dass ich nur noch etwa 113MB/s erreichen konnte. Das Problem war jedoch schnell gefunden, ich habe parallel zum laufenden Test den Taskmanager geöffnet und sah sofort das Schlamassel. Meine Workstation übermittelte die Daten nur noch über die 1G Schnittstelle, obwohl ich die Freigabe der NAS explizit über eine IP der vier 10G NICs der NAS angesprochen habe. 😮
Dann habe ich als nächstes spasseshalber noch den W-LAN Adapter in der Workstation aktiviert und den Test wiederholt.
Nun darfst du drei Mal raten worüber anschliessend der SMB Traffic ging?
Natürlich über den noch lahmeren W-LAN Adapter …
Dann habe ich W-LAN und die 1G NIC deaktiviert und sofort ging der SMB Traffic auf die vier 10G NIC über.
Meine 1G NIC (Intel I219-V) unterstützt kein RDMA und der W-LAN Adapter schon dreimal nicht.
Daher hat das MS-Murks-SMB-Multichannel-Downscaling auch nichts mit RDMA zu tun, dieses nimmt aus nur Microsoft bekannten und nicht dokumentierten Gründen immer die langsamste, zur Verfügung stehende IP-Verbindung und nicht die schnellste wie es sein sollte.
@microsoft … WTF ???
Zu diesem Thema habe ich auch etwas Unangenehmes am letzten Wochenende rausgefunden, kann jetzt aber nicht näher darauf eingehen, weil mir gerade die Zeit etwas davonrennt. 🙃
Aber dennoch eine Frage an dieser Stelle.
Verwendest du CSVs (Cluster Shared Volume) in deiner HV Umgebung?
Falls ja:
A: mit welchem Dateiformat hast du diese formatier NTFS oder REFS?
B: kannst du mir bitte die Ausgabe von „Get-ClusterSharedVolumeState“ posten, ich bin nur am „State“ interessiert.
OK, war jetzt doch mehr als eine Frage, die Infos daraus sind aber extrem wichtig … 😎
So, jetzt muss ich aber flitzen.
Grüsse aus BaWü
Alex
Ja ohne RSS wird man bei 400MB/s gecapt sozusagen - wegen der CPU. Warum es bei deinem Server trotzdem mit 10Gb/s übertragen hat kann ich dir nicht sagen - entweder RSS war nicht wirklich aus, oder es lief über SMB Multichannel was du ja jetzt auch entdeckt hast...doch auch das SMB3.0 Feature (Multichannel, gibts ein Windows 8) hat auch so seine tücken musste ich feststellen
https://www.mcseboard.de/topic/217424-smb-multichannel-nutze-nur-2-von-4 ...
https://www.mcseboard.de/topic/217424-smb-multichannel-nutze-nur-2-von-4 ...
Dieses Fehlverhalten, das bevorzugen von langsameren NIC's unter Verwendung von SMB Multichannel kann ich aus zwei eigenen jüngsten Erfahrungen 1A bestätigen.
egal wieschnell welche Netzwerkkarte angebunden ist, es werden immer die mit RDMA bevorzugt behandelt - da muss MS dringend nachbessern und vieleicht auch mal prüfen wieschnell die RDMA fähige karte angebunden ist, und ob es nicht doch andere NICs gibt, die deutlich schneller angebunden sind. Ich weiß zwar trotzdem noch nicht warum es bei mir diese einbrüche gibt,
Deine Vermutung mit RDMA hingegen kann ich, glaube ich jedoch wiederlegen.
Meine letzten Erfahrungen mit dem Problem haben gezeigt, dass bei der Anwendung von SMB Multichannel, unabhängig vom RDMA, generell die langsamste verfügbare LAN Verbindung bevorzugt wird.
Ich habe zum Thema SMB Multichannel bei Spiceworks gerade auch die folgende Diskussion am Laufen.
https://community.spiceworks.com/topic/2265556-mystical-loadbalancing-by ...
Vor etwa zwei Wochen ist mir bei Testen etwas Komisches aufgefallen, das ich bisher nirgends thematisiert habe.
Aber vorher ein paar relevante technische Details.
Die verwendete Workstation hat 5 x 10G NICs, 1 x 1G und 1 x W-LAN.
Bei den ersten Tests waren nur die vier X710 direkt zu den vier 10G NICs der NAS verbunden, alle anderen NICs der Workstation waren offline, zusätzlich war die NAS mit einem der zwei 1G onboard NICs ebenfalls am Netz per Switch zwecks Managements angeschlossen.
In dieser Konstellation (an der Workstation nur die vier 10G NICs online) hat das SMB Multichannel wunderbar funktioniert. Ich konnte nur mit einem Stream alle vier 10G NICs fast vollständig auslasten, siehe Screenshot bei Spiceworks.
Dann musste ich mit der Workstation kurz ins Internet und habe dazu die 1G NIC ans Netz gehängt über welches auch die 1G NIC der NAS erreichbar war. Anschliessend habe ich vergessen die 1G NIC der Workstation wieder zu deaktivieren und wunderte mich bei den darauffolgenden Tests, dass ich nur noch etwa 113MB/s erreichen konnte. Das Problem war jedoch schnell gefunden, ich habe parallel zum laufenden Test den Taskmanager geöffnet und sah sofort das Schlamassel. Meine Workstation übermittelte die Daten nur noch über die 1G Schnittstelle, obwohl ich die Freigabe der NAS explizit über eine IP der vier 10G NICs der NAS angesprochen habe. 😮
Dann habe ich als nächstes spasseshalber noch den W-LAN Adapter in der Workstation aktiviert und den Test wiederholt.
Nun darfst du drei Mal raten worüber anschliessend der SMB Traffic ging?
Natürlich über den noch lahmeren W-LAN Adapter …
Dann habe ich W-LAN und die 1G NIC deaktiviert und sofort ging der SMB Traffic auf die vier 10G NIC über.
Meine 1G NIC (Intel I219-V) unterstützt kein RDMA und der W-LAN Adapter schon dreimal nicht.
Daher hat das MS-Murks-SMB-Multichannel-Downscaling auch nichts mit RDMA zu tun, dieses nimmt aus nur Microsoft bekannten und nicht dokumentierten Gründen immer die langsamste, zur Verfügung stehende IP-Verbindung und nicht die schnellste wie es sein sollte.
@microsoft … WTF ???
aber gut, das könnte was mit dem Raidcontroller zutun haben...auch wenn der in der zeit wo er schnell kopiert deutlich mehr daten transferriert hat, als in den Controller cache passen würde...
Zu diesem Thema habe ich auch etwas Unangenehmes am letzten Wochenende rausgefunden, kann jetzt aber nicht näher darauf eingehen, weil mir gerade die Zeit etwas davonrennt. 🙃
Aber dennoch eine Frage an dieser Stelle.
Verwendest du CSVs (Cluster Shared Volume) in deiner HV Umgebung?
Falls ja:
A: mit welchem Dateiformat hast du diese formatier NTFS oder REFS?
B: kannst du mir bitte die Ausgabe von „Get-ClusterSharedVolumeState“ posten, ich bin nur am „State“ interessiert.
OK, war jetzt doch mehr als eine Frage, die Infos daraus sind aber extrem wichtig … 😎
So, jetzt muss ich aber flitzen.
Grüsse aus BaWü
Alex
Moin Assassin,
kleiner Nachtrag zu unserem SMB Multichannel Thema.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
"If you plan to use a single network adapter without RSS, you do not benefit from multiple network connections, and therefore, SMB Multichannel is not used. Also, if you plan to use network adapters of different speeds, SMB Multichannel automatically selects the fastest network adapter because network adapters that are the same type, such as RDMA, RSS, or none, and have the same speed are simultaneously used by SMB Multichannel. The slower network adapters are idle."
Wenn ich MS nun richtig verstehe, so sollte das "MS-Murks-SMB-Multichannel-Downscaling" 🙃 eigentlich nicht existieren, zumal der Umstand mit langsameren und NO RSS & RDMA NICs bei der Implementierung berücksichtigt wurde.
Ich werde das Thema die nächsten Tage ein bisschen auseinanderpflügen, da dieser Punkt mitunter auch in der diskutierten Netzwerkproblematik eine wesentliche Rolle mitspielen kann, aber auch REFS, CSV und vor allem RSS. 😉
Grüsse aus BaWü
Alex
kleiner Nachtrag zu unserem SMB Multichannel Thema.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
"If you plan to use a single network adapter without RSS, you do not benefit from multiple network connections, and therefore, SMB Multichannel is not used. Also, if you plan to use network adapters of different speeds, SMB Multichannel automatically selects the fastest network adapter because network adapters that are the same type, such as RDMA, RSS, or none, and have the same speed are simultaneously used by SMB Multichannel. The slower network adapters are idle."
Wenn ich MS nun richtig verstehe, so sollte das "MS-Murks-SMB-Multichannel-Downscaling" 🙃 eigentlich nicht existieren, zumal der Umstand mit langsameren und NO RSS & RDMA NICs bei der Implementierung berücksichtigt wurde.
Ich werde das Thema die nächsten Tage ein bisschen auseinanderpflügen, da dieser Punkt mitunter auch in der diskutierten Netzwerkproblematik eine wesentliche Rolle mitspielen kann, aber auch REFS, CSV und vor allem RSS. 😉
Grüsse aus BaWü
Alex
Ok, dass MS immer die langsamste Verbindung bevorzugt habe ich jetzt nicht getestet, weil so absurd können die MS Programmierer doch nocht programmieren, oder?
wegen dem CSV - ja nutzen wir, aber über eine Software welche das ClusterShare bereitstellt um die Festplatte im Server direkt zu nutzen. Die Festplatten werden über 2x 16GB FC Synchronisiert über beide Knoten hinweg. Software die von Datacore SANsymphony.
der GET-ClusterSharedVolumeState gibt das aus:
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : Clusterdatenträger 1
Node : ***-HV02
StateInfo : Direct
VolumeFriendlyName : Volume1
VolumeName : \\?\Volume{a81f01fd-ec9d-4ae4-b944-83ca26b19599}\
bei dem Test mit dem Kopieren übeer die 2x 10G anbindung über SMB3.0 habe ich aber nicht aufs CSV kopiert, habe auf Knoten1 eine VM erstellt mit einem 64GB RAM-Drive und habe von da auf eine andere VM auf Knoten2 in ein RAM-Drive reinkopiert - auch da gab es immer wieder einbrüche
wegen dem CSV - ja nutzen wir, aber über eine Software welche das ClusterShare bereitstellt um die Festplatte im Server direkt zu nutzen. Die Festplatten werden über 2x 16GB FC Synchronisiert über beide Knoten hinweg. Software die von Datacore SANsymphony.
der GET-ClusterSharedVolumeState gibt das aus:
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : Clusterdatenträger 1
Node : ***-HV02
StateInfo : Direct
VolumeFriendlyName : Volume1
VolumeName : \\?\Volume{a81f01fd-ec9d-4ae4-b944-83ca26b19599}\
bei dem Test mit dem Kopieren übeer die 2x 10G anbindung über SMB3.0 habe ich aber nicht aufs CSV kopiert, habe auf Knoten1 eine VM erstellt mit einem 64GB RAM-Drive und habe von da auf eine andere VM auf Knoten2 in ein RAM-Drive reinkopiert - auch da gab es immer wieder einbrüche
Moin Assassin,
Da muss ich ein wenig zurückrudern, ich habe dieses Problem genau zwei Mal hintereinander beobachten können.
Bei einem der Fälle war noch ein zweiter Techniker per TeamViewer auf dem System, der sich ebenfalls über das sonderbare Verhalten sehr gewundert hat.
Aktuell kann ich das Problem jedoch nicht mehr nachstellen. Momentan läuft alles wie es sein sollte, die Workstation nutzt immer die schnellste Verbindung, auch wenn ich per Freigabe die 1G anspreche kommen die Daten per 4 x 10G. 😀
Kein Plan, was die Kiste vorher hatte, ich werde den Punkt auf jeden Fall im Auge behalten.
Das sieht gut aus, vor allem der Punkt "StateInfo : Direct". 👍
Ist das Volume mit NTFS formatiert?
🤔 ... muss mal darüber Hirnen
Gruss Alex
Ok, dass MS immer die langsamste Verbindung bevorzugt habe ich jetzt nicht getestet, weil so absurd können die MS Programmierer doch nocht programmieren, oder?
Da muss ich ein wenig zurückrudern, ich habe dieses Problem genau zwei Mal hintereinander beobachten können.
Bei einem der Fälle war noch ein zweiter Techniker per TeamViewer auf dem System, der sich ebenfalls über das sonderbare Verhalten sehr gewundert hat.
Aktuell kann ich das Problem jedoch nicht mehr nachstellen. Momentan läuft alles wie es sein sollte, die Workstation nutzt immer die schnellste Verbindung, auch wenn ich per Freigabe die 1G anspreche kommen die Daten per 4 x 10G. 😀
Kein Plan, was die Kiste vorher hatte, ich werde den Punkt auf jeden Fall im Auge behalten.
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : Clusterdatenträger 1
Node : ***-HV02
StateInfo : Direct
VolumeFriendlyName : Volume1
VolumeName : \\?\Volume{a81f01fd-ec9d-4ae4-b944-83ca26b19599}\
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : Clusterdatenträger 1
Node : ***-HV02
StateInfo : Direct
VolumeFriendlyName : Volume1
VolumeName : \\?\Volume{a81f01fd-ec9d-4ae4-b944-83ca26b19599}\
Das sieht gut aus, vor allem der Punkt "StateInfo : Direct". 👍
Ist das Volume mit NTFS formatiert?
bei dem Test mit dem Kopieren übeer die 2x 10G anbindung über SMB3.0 habe ich aber nicht aufs CSV kopiert, habe auf Knoten1 eine VM erstellt mit einem 64GB RAM-Drive und habe von da auf eine andere VM auf Knoten2 in ein RAM-Drive reinkopiert - auch da gab es immer wieder einbrüche
🤔 ... muss mal darüber Hirnen
Gruss Alex
Moin Assassin,
kannst du bitte die Ausgabe von Get-NetAdapterRss posten, danke.
Gruss Alex
kannst du bitte die Ausgabe von Get-NetAdapterRss posten, danke.
Gruss Alex
Moin Assassin,
ich würde gerne unsere 400MB/s Limit ohne RSS Diskussion wieder aufwärmen.
Diese Limitierung wird in anderen Foren und auch Bücher sehr oft erwähnt …
https://wiki.webperfect.ch/index.php?title=Hyper-V:_Receive_Side_Scaling ...
http://www.darrylvanderpeijl.com/windows-server-2016-networking-optimiz ...
https://books.google.de/books?id=vMOiBQAAQBAJ&pg=PT216&lpg=PT216 ...
https://books.google.de/books?id=j8mcDQAAQBAJ&pg=PA154&lpg=PA154 ...
Aber an welche Architektur/Bus dieses Limit genau gebunden ist, wird jedoch nie thematisiert. 🤨🤔
Ich selber kenne in der aktuellen CPU Architektur auch nichts, was dieses harte Limit befürworten würde und habe deshalb die Tage eine kleine Testreihe auf meiner Workstation gegen ein 10G fähiges und sehr flinkes NAS durchlaufen lassen.
Das Erste Ergebnis ist ohne RSS und ohne SMB Multichannel
Es wird wie erwartet nur Kern 1 belastet, aber ich erreiche auch mit diesem locker schon 10G.
Zweites Ergebnis ist ohne RSS aber mit SMB Multichannel (2x10G).
Hier werden nun zwei Kerne belastet und ich komme auch ohne RSS hier locker auf die vollen 20G.
Nun das gleiche Spielchen mit 1x10G und RSS.
OK, es wird ein anderer Kern angesprochen, aber das wars auch.
Und mit 2x10G, RSS und SMB-MC.
Sieht es auch nicht viel anders aus als ohne RSS.
---
Ich würde nun gerne die folgende These aufstellen.
Ein hartes 4GB Limit pro Kern und NIC gibt und gab es nie.
Vielmehr ist die maximal mögliche Übertragungskapazität einer NIC, von der Leistungsfähigkeit des Cores abhängig, an den diese gemapt ist. Die die Leistung des Cores häng wiederum hauptsächlich von seiner Taktrate ab als auch von der Architektur.
Als mögliche Faustregel würde ich aktuell eher ca. 2 – 2,5 Gbit/s pro GHz und Core aufstellen.
Meine CPU (i9-9820X) läuft aktuell mit einem Basistakt von 4,5 GHz (habe leicht nachgeholfen 🤪) über alle zehn (mit HT zwanzig, aber die zählen bei NIC Verkehr nicht) Kerne, daher reicht auch ein Kern aus, um 10G vollständig zu handeln. Somit hätte meine CPU aktuell ein Netzwerkübertragungsgesamtbudget von 10 Cores x 4,5 GHz x 2,5 Gbit/s = 112,5 Gbit/s.
Ein mindestens sechs Mal teurer Xeon Platinum 8253 schafft mit seinem Basistakt von 2,2 hingegen nur die Hälfte pro Core und (16Core x 2,20 GHz x 2,5 Gbit/s = 88 Gbit/s) auch in der Summe nicht mehr.
Fragen und Kritik sind Gerne Willkommen.
Grüsse aus BaWü
Alex
Ja ohne RSS wird man bei 400MB/s gecapt sozusagen - wegen der CPU. Warum es bei deinem Server trotzdem mit 10Gb/s übertragen hat kann ich dir nicht sagen - entweder RSS war nicht wirklich aus, oder es lief über SMB Multichannel was du ja jetzt auch entdeckt hast..
ich würde gerne unsere 400MB/s Limit ohne RSS Diskussion wieder aufwärmen.
Diese Limitierung wird in anderen Foren und auch Bücher sehr oft erwähnt …
https://wiki.webperfect.ch/index.php?title=Hyper-V:_Receive_Side_Scaling ...
http://www.darrylvanderpeijl.com/windows-server-2016-networking-optimiz ...
https://books.google.de/books?id=vMOiBQAAQBAJ&pg=PT216&lpg=PT216 ...
https://books.google.de/books?id=j8mcDQAAQBAJ&pg=PA154&lpg=PA154 ...
Aber an welche Architektur/Bus dieses Limit genau gebunden ist, wird jedoch nie thematisiert. 🤨🤔
Ich selber kenne in der aktuellen CPU Architektur auch nichts, was dieses harte Limit befürworten würde und habe deshalb die Tage eine kleine Testreihe auf meiner Workstation gegen ein 10G fähiges und sehr flinkes NAS durchlaufen lassen.
Das Erste Ergebnis ist ohne RSS und ohne SMB Multichannel
Es wird wie erwartet nur Kern 1 belastet, aber ich erreiche auch mit diesem locker schon 10G.
Zweites Ergebnis ist ohne RSS aber mit SMB Multichannel (2x10G).
Hier werden nun zwei Kerne belastet und ich komme auch ohne RSS hier locker auf die vollen 20G.
Nun das gleiche Spielchen mit 1x10G und RSS.
OK, es wird ein anderer Kern angesprochen, aber das wars auch.
Und mit 2x10G, RSS und SMB-MC.
Sieht es auch nicht viel anders aus als ohne RSS.
---
Ich würde nun gerne die folgende These aufstellen.
Ein hartes 4GB Limit pro Kern und NIC gibt und gab es nie.
Vielmehr ist die maximal mögliche Übertragungskapazität einer NIC, von der Leistungsfähigkeit des Cores abhängig, an den diese gemapt ist. Die die Leistung des Cores häng wiederum hauptsächlich von seiner Taktrate ab als auch von der Architektur.
Als mögliche Faustregel würde ich aktuell eher ca. 2 – 2,5 Gbit/s pro GHz und Core aufstellen.
Meine CPU (i9-9820X) läuft aktuell mit einem Basistakt von 4,5 GHz (habe leicht nachgeholfen 🤪) über alle zehn (mit HT zwanzig, aber die zählen bei NIC Verkehr nicht) Kerne, daher reicht auch ein Kern aus, um 10G vollständig zu handeln. Somit hätte meine CPU aktuell ein Netzwerkübertragungsgesamtbudget von 10 Cores x 4,5 GHz x 2,5 Gbit/s = 112,5 Gbit/s.
Ein mindestens sechs Mal teurer Xeon Platinum 8253 schafft mit seinem Basistakt von 2,2 hingegen nur die Hälfte pro Core und (16Core x 2,20 GHz x 2,5 Gbit/s = 88 Gbit/s) auch in der Summe nicht mehr.
Fragen und Kritik sind Gerne Willkommen.
Grüsse aus BaWü
Alex
Hallo Alex,
erstmals VIELEN DANK für deine Arbeit hier! Respekt meiner seits!
ich glaube, dass ich das selbe Problem habe. Wir haben einen neuen Server bekommen in welchem X710-T NIC verbaut ist mit 10GB (Switch ist ein SX350 Cisco mit 10GB Ports). Ich habe im Hyper-V 4*10GB NICs in ein TEAMing zusammen gefasst (40GB/s) und verwende dies im vSwitch für meine Virtuellen Maschinen. Sowohl Hyper-V als auch die VM's sind Windows 2019 und unsere Clients sind Windows 10 Pro (1909). Nachdem wir unsere ERP Software auf unseren neuen Server migriert haben (EXE und DLL Files liegen auf einer Freigabe - Die Clients starten die ERPSoftware.exe über die Freigabe vom Windows 2019 Server) Das starten und das Arbeiten in der ERP Software war dermaßen langsam, so dass wir die Migration abgebrochen haben.
Nun habe ich folgendes getestet:
Clients sind alle 1 Gigabit am Netzwerk angeschlossen. Kopiere ich eine große Datei auf unseren FILE-Server so bleibt die Übertragung konstant bei 114MB/s. Kopiere ich dann die selbe Datei vom File-Server auf den Client zurück so variiert die Geschwindigkeit zwischen 30MB/s und 100MB/s sie schwankt jedoch rauf und runter und ist nie konstant - ganz zufällig!
Nun habe ich mir den ganzen Thread durchgelesen und möchte Fragen WO GENAU der Fehler liegt und WAS GENAU die Lösung ist, da ich mich etwas verwirrt habe????
Ist es so, dass Windows 2019 mit dem NIC-TEAMING auf 40GB/s nicht zurecht kommt aufgrund von RSS? Wäre das Problem behoben wenn beispielsweise kein NIC-TEAMING vorhanden wäre und ich nur über ein 10GB Kabel den vSwitch angelegt hätte? Was bringt mir die Einrichtung wenn ich RSS deaktiviere und dann nur noch 400MB/s über die Leitung bekomme?
WAS GENAU ist den nun die Lösung, sieht dies folgendermaßen aus:
1.) RECV über den Adapter für IPv4 und IPv6 deaktivieren?
2.) RSC für vSwitch deaktivieren über: Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $false
3.) dein Script ausführen:
... Wie mache ich dieses Script rückgängig wenn etwas sein sollte? oder brauche ich dieses Script nicht wirklich am Server? würden Punkt 1 und 2 reichen?
oder ist es dieses Script welches ich brauche?
... Muss ich punkt 1,2 und 3 auch auf der VM ausführen oder nur am Hyper-V Host?
... Muss ich VMQ auch deaktivieren oder ist das nur ein "nice to have"???
... Kann man sagen dass es ein "Programmier-Bug" von Windows Server 2019 ist? gibt es schon ein Ticket bei Microsoft?
Ich bitte um kurze Hilfestellung. DANKE!
lg Samet
erstmals VIELEN DANK für deine Arbeit hier! Respekt meiner seits!
ich glaube, dass ich das selbe Problem habe. Wir haben einen neuen Server bekommen in welchem X710-T NIC verbaut ist mit 10GB (Switch ist ein SX350 Cisco mit 10GB Ports). Ich habe im Hyper-V 4*10GB NICs in ein TEAMing zusammen gefasst (40GB/s) und verwende dies im vSwitch für meine Virtuellen Maschinen. Sowohl Hyper-V als auch die VM's sind Windows 2019 und unsere Clients sind Windows 10 Pro (1909). Nachdem wir unsere ERP Software auf unseren neuen Server migriert haben (EXE und DLL Files liegen auf einer Freigabe - Die Clients starten die ERPSoftware.exe über die Freigabe vom Windows 2019 Server) Das starten und das Arbeiten in der ERP Software war dermaßen langsam, so dass wir die Migration abgebrochen haben.
Nun habe ich folgendes getestet:
Clients sind alle 1 Gigabit am Netzwerk angeschlossen. Kopiere ich eine große Datei auf unseren FILE-Server so bleibt die Übertragung konstant bei 114MB/s. Kopiere ich dann die selbe Datei vom File-Server auf den Client zurück so variiert die Geschwindigkeit zwischen 30MB/s und 100MB/s sie schwankt jedoch rauf und runter und ist nie konstant - ganz zufällig!
Nun habe ich mir den ganzen Thread durchgelesen und möchte Fragen WO GENAU der Fehler liegt und WAS GENAU die Lösung ist, da ich mich etwas verwirrt habe????
Ist es so, dass Windows 2019 mit dem NIC-TEAMING auf 40GB/s nicht zurecht kommt aufgrund von RSS? Wäre das Problem behoben wenn beispielsweise kein NIC-TEAMING vorhanden wäre und ich nur über ein 10GB Kabel den vSwitch angelegt hätte? Was bringt mir die Einrichtung wenn ich RSS deaktiviere und dann nur noch 400MB/s über die Leitung bekomme?
WAS GENAU ist den nun die Lösung, sieht dies folgendermaßen aus:
1.) RECV über den Adapter für IPv4 und IPv6 deaktivieren?
2.) RSC für vSwitch deaktivieren über: Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $false
3.) dein Script ausführen:
Set-NetTCPSetting -SettingName "InternetCustom" -CongestionProvider CTCP
Set-NetTCPSetting -SettingName "InternetCustom" -DelayedAckTimeoutMs 50
Set-NetTCPSetting -SettingName "InternetCustom" -ForceWS Disabled
Set-NetTCPSetting -SettingName "DatacenterCustom" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "DatacenterCustom" -CwndRestart True
Set-NetTCPSetting -SettingName "DatacenterCustom" -ForceWS Disabled
Set-NetTCPSetting -SettingName "Compat" -ForceWS Disabled
Set-NetTCPSetting -SettingName "Datacenter" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "Datacenter" -CwndRestart True
Set-NetTCPSetting -SettingName "Datacenter" -ForceWS Disabled
Set-NetTCPSetting -SettingName "Internet" -CongestionProvider CTCP
Set-NetTCPSetting -SettingName "InternetCustom" -DelayedAckTimeoutMs 50
Set-NetTCPSetting -SettingName "Internet" -ForceWS Disabled ... Wie mache ich dieses Script rückgängig wenn etwas sein sollte? oder brauche ich dieses Script nicht wirklich am Server? würden Punkt 1 und 2 reichen?
oder ist es dieses Script welches ich brauche?
#NATIVE2019, HV2019, VM2019
#Get-NetTCPSetting | ft -AutoSize
Set-NetTCPSetting -SettingName "InternetCustom" -CongestionProvider CTCP
Set-NetTCPSetting -SettingName "InternetCustom" -DelayedAckTimeoutMs 50
Set-NetTCPSetting -SettingName "InternetCustom" -ForceWS Disabled
Set-NetTCPSetting -SettingName "DatacenterCustom" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "DatacenterCustom" -CwndRestart True
Set-NetTCPSetting -SettingName "DatacenterCustom" -ForceWS Disabled
Set-NetTCPSetting -SettingName "Compat" -ForceWS Disabled
Set-NetTCPSetting -SettingName "Datacenter" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "Datacenter" -CwndRestart True
Set-NetTCPSetting -SettingName "Datacenter" -ForceWS Disabled
Set-NetTCPSetting -SettingName "Internet" -CongestionProvider CTCP
Set-NetTCPSetting -SettingName "InternetCustom" -DelayedAckTimeoutMs 50
Set-NetTCPSetting -SettingName "Internet" -ForceWS Disabled
#NATIVE2019, HV2019, VM2019
#netsh int tcp show global
netsh int tcp set global RSS=Disabled
netsh int tcp set global RSC=Disabled
#VM2019
#Get-NetAdapterAdvancedProperty | ft -AutoSize
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Large Send Offload Version 2 (IPv4)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Large Send Offload Version 2 (IPv6)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Recv Segment Coalescing (IPv4)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Recv Segment Coalescing (IPv6)" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Set-NetAdapterAdvancedProperty -DisplayName "Receive Side Scaling" -DisplayValue "Disabled" -NoRestart
Get-NetAdapter | Restart-NetAdapter
#NATIVE2019, HV2019, VM2019
#Get-Net6to4Configuration | ft -AutoSize
Set-Net6to4Configuration -State Disabled
#NATIVE2019, HV2019, VM2019
#Get-NetIsatapConfiguration | ft -AutoSize
Set-NetIsatapConfiguration -State Disabled
#NATIVE2019, HV2019, VM2019
#Get-NetAdapter | Get-NetAdapterBinding
Get-NetAdapter | Disable-NetAdapterBinding –ComponentID ms_tcpip6... Muss ich punkt 1,2 und 3 auch auf der VM ausführen oder nur am Hyper-V Host?
... Muss ich VMQ auch deaktivieren oder ist das nur ein "nice to have"???
... Kann man sagen dass es ein "Programmier-Bug" von Windows Server 2019 ist? gibt es schon ein Ticket bei Microsoft?
Ich bitte um kurze Hilfestellung. DANKE!
lg Samet
Moin Samet,
als erstes sorry für die Verzögerung, habe dich aufgrund anderer Baustellen leicht aus dem Auge verloren.
Das kommt ganz darauf an, wie du dein Teaming realisiert hast. Wenn du das Teaming klassisch über das OS gemacht hast, dann steht RSS und RSC auf den NIC’S eh nicht zur Verfügung, da es bei dieser Teamingvariante schlichtweg nicht unterstützt wird. Die beiden Features stehen nur „durchgängig“ zur Verfügung, wenn du das Teaming über SET realisiert hast.
Siehe auch ….
https://www.windowspro.de/marcel-kueppers/statt-nic-teaming-switch-embed ...
Ohne RSS ist die Übertragungsrate tatsächlich limitiert, da die Netzwerkkarte/vSwitch für die Abarbeitung des Workloads jeweils nur einen Kern nutzen können, aber das Limit mit den 400 MB/s ist ein Ammenmärchen.
Siehe hierzu …
https://community.spiceworks.com/topic/2269972-weird-4gbit-s-nic-limit-w ...
Wenn du die NUMA Zuornung und die RSS Feinkonfiguration nicht machen möchtest oder kannst dann definitiv ja. Habe erst jetzt eine Fall von einem anderen Systemintegrator gehabt, bei dem das Problem erst durch deaktivieren von RSC auf dem vSwitch verschwunden ist.
Aber nur das folgende.
Mit dem folgenden Script …
---
Für die beiden oberen Befehle gilt das selbe wie auch beim Switch, wenn NUMA-Zuordnung und RSS richtig konfiguriert sind, so musst du weder RSS noch RSC deaktivieren. Wenn das nicht möglich ist, dann auf jeden Fall beides ausschalten.
Bitte immer darauf achten, dass jegliches Feature immer durchgängig (HV & VM & vSwitch & NICs & vNICs & u.s.w.) entweder aktiviert oder deaktiviert ist.
Ich habe bei den aktuellen Konfigurationen sowohl SRIOV als auch VMQ aktiviert gelassen und habe bisher absolut keinen Stress. Unter dem Strich sorgen diese Features bei Netzwerklast unter anderem für eine Entlastung der CPU und sind somit nicht unrelevant.
Microsoft hat bei 2019er definitiv einige Böcke geschossen, aber auch die NIC Hersteller sind nicht ganz unschuldig, da falsche Defaulteinstellungen und oder gänzlich fehlende wichtige Einstellungsoptionen. 🤢
Grüsse aus BaWü
Alex
als erstes sorry für die Verzögerung, habe dich aufgrund anderer Baustellen leicht aus dem Auge verloren.
Ist es so, dass Windows 2019 mit dem NIC-TEAMING auf 40GB/s nicht zurecht kommt aufgrund von RSS? Wäre das Problem behoben wenn beispielsweise kein NIC-TEAMING vorhanden wäre und ich nur über ein 10GB Kabel den vSwitch angelegt hätte? Was bringt mir die Einrichtung wenn ich RSS deaktiviere und dann nur noch 400MB/s über die Leitung bekomme?
Das kommt ganz darauf an, wie du dein Teaming realisiert hast. Wenn du das Teaming klassisch über das OS gemacht hast, dann steht RSS und RSC auf den NIC’S eh nicht zur Verfügung, da es bei dieser Teamingvariante schlichtweg nicht unterstützt wird. Die beiden Features stehen nur „durchgängig“ zur Verfügung, wenn du das Teaming über SET realisiert hast.
Siehe auch ….
https://www.windowspro.de/marcel-kueppers/statt-nic-teaming-switch-embed ...
Ohne RSS ist die Übertragungsrate tatsächlich limitiert, da die Netzwerkkarte/vSwitch für die Abarbeitung des Workloads jeweils nur einen Kern nutzen können, aber das Limit mit den 400 MB/s ist ein Ammenmärchen.
Siehe hierzu …
https://community.spiceworks.com/topic/2269972-weird-4gbit-s-nic-limit-w ...
WAS GENAU ist den nun die Lösung, sieht dies folgendermaßen aus:
1.) RECV über den Adapter für IPv4 und IPv6 deaktivieren?
Muss nicht sein.1.) RECV über den Adapter für IPv4 und IPv6 deaktivieren?
2.) RSC für vSwitch deaktivieren über: Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $false
Wenn du die NUMA Zuornung und die RSS Feinkonfiguration nicht machen möchtest oder kannst dann definitiv ja. Habe erst jetzt eine Fall von einem anderen Systemintegrator gehabt, bei dem das Problem erst durch deaktivieren von RSC auf dem vSwitch verschwunden ist.
3.) dein Script ausführen:
Aber nur das folgende.
Set-NetTCPSetting -SettingName "InternetCustom" -CongestionProvider CTCP
Set-NetTCPSetting -SettingName "DatacenterCustom" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "Datacenter" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "Internet" -CongestionProvider CTCP ... Wie mache ich dieses Script rückgängig wenn etwas sein sollte? oder brauche ich dieses Script nicht wirklich am Server? würden Punkt 1 und 2 reichen?
Mit dem folgenden Script …
Set-NetTCPSetting -SettingName "InternetCustom" -CongestionProvider CUBIC
Set-NetTCPSetting -SettingName "DatacenterCustom" -CongestionProvider CUBIC
Set-NetTCPSetting -SettingName "Datacenter" -CongestionProvider CUBIC
Set-NetTCPSetting -SettingName "Internet" -CongestionProvider CUBIC ---
netsh int tcp set global RSS=Disabled
netsh int tcp set global RSC=DisabledFür die beiden oberen Befehle gilt das selbe wie auch beim Switch, wenn NUMA-Zuordnung und RSS richtig konfiguriert sind, so musst du weder RSS noch RSC deaktivieren. Wenn das nicht möglich ist, dann auf jeden Fall beides ausschalten.
... Muss ich punkt 1,2 und 3 auch auf der VM ausführen oder nur am Hyper-V Host?
Bitte immer darauf achten, dass jegliches Feature immer durchgängig (HV & VM & vSwitch & NICs & vNICs & u.s.w.) entweder aktiviert oder deaktiviert ist.
... Muss ich VMQ auch deaktivieren oder ist das nur ein "nice to have"???
Ich habe bei den aktuellen Konfigurationen sowohl SRIOV als auch VMQ aktiviert gelassen und habe bisher absolut keinen Stress. Unter dem Strich sorgen diese Features bei Netzwerklast unter anderem für eine Entlastung der CPU und sind somit nicht unrelevant.
... Kann man sagen dass es ein "Programmier-Bug" von Windows Server 2019 ist? gibt es schon ein Ticket bei Microsoft?
Microsoft hat bei 2019er definitiv einige Böcke geschossen, aber auch die NIC Hersteller sind nicht ganz unschuldig, da falsche Defaulteinstellungen und oder gänzlich fehlende wichtige Einstellungsoptionen. 🤢
Grüsse aus BaWü
Alex
Moin Zusammen,
sorry, das ich diesen Post hier etwas vernachlässigt habe, aber ich kann nicht gleichzeitig zwei Foren mit unterschiedlichen Sprachen inhaltlich bedienen, dazu fehlt mir momentan schlichtweg die Zeit. ☮
Heureka, ich habe die Tage, das wahre Problem hinter unserem Problem herausgefunden. 🙃😁
Siehe folgenden Beitrag bei SpiceWorks (englisch):
https://community.spiceworks.com/topic/2282473-the-real-disaster-behind- ...
Da hat wohl die gesamte Netzwerkartenindustrie seit 10 Jahren ihre Hausaufgaben nicht so richtig bei den Treibern gemacht. 😔
Grüsse aus BaWü
Alex
sorry, das ich diesen Post hier etwas vernachlässigt habe, aber ich kann nicht gleichzeitig zwei Foren mit unterschiedlichen Sprachen inhaltlich bedienen, dazu fehlt mir momentan schlichtweg die Zeit. ☮
Heureka, ich habe die Tage, das wahre Problem hinter unserem Problem herausgefunden. 🙃😁
Siehe folgenden Beitrag bei SpiceWorks (englisch):
https://community.spiceworks.com/topic/2282473-the-real-disaster-behind- ...
Da hat wohl die gesamte Netzwerkartenindustrie seit 10 Jahren ihre Hausaufgaben nicht so richtig bei den Treibern gemacht. 😔
Grüsse aus BaWü
Alex
Ich habe den Spicework überflogen.
Erstmal Vielen Dank dir, das du da soviel Zeit und Energie reingesteckt hast! Respekt.
Da ich nun auf das gleiche Problem gelaufen bin, muss ich jetzt aber auch nochmal nachfragen.
Bei Spiceworks hab ich nicht unbedingt alles verstanden oder in die richtige Reihenfolge gebracht.
Man sollte nach wie vor den CongestionProvider von Cubic weg umstellen oder?
Wie sieht das mit einem Hyper V Cluster aus? Nur die VM Schnittstelle oder auch die für den Clusterbetrieb und die Shared Volume Umleitung?
PS: ach Quark, das ist ja eine allgemeine Einstellung die dann eh für alle Adapter gilt oder? Das heißt aber auch, am besten die Verbindung zum Storage vorher trennen ja?
PPS: Das kopieren von großen Dateien geht in beiden Richtungen übrigens durchgängig schnell. Aber ähnlich wie bei samet22 wird bei uns ein Programm direkt vom SMB Share gestartet. Von einem Server 2012 Share geht wie lokal installiert. Bei Start kommt sofort die Anmeldemaske. Und das dauert vom Server 2019 durchaus 5-10 Sek.
Erstmal Vielen Dank dir, das du da soviel Zeit und Energie reingesteckt hast! Respekt.
Da ich nun auf das gleiche Problem gelaufen bin, muss ich jetzt aber auch nochmal nachfragen.
Bei Spiceworks hab ich nicht unbedingt alles verstanden oder in die richtige Reihenfolge gebracht.
Man sollte nach wie vor den CongestionProvider von Cubic weg umstellen oder?
Wie sieht das mit einem Hyper V Cluster aus? Nur die VM Schnittstelle oder auch die für den Clusterbetrieb und die Shared Volume Umleitung?
PS: ach Quark, das ist ja eine allgemeine Einstellung die dann eh für alle Adapter gilt oder? Das heißt aber auch, am besten die Verbindung zum Storage vorher trennen ja?
PPS: Das kopieren von großen Dateien geht in beiden Richtungen übrigens durchgängig schnell. Aber ähnlich wie bei samet22 wird bei uns ein Programm direkt vom SMB Share gestartet. Von einem Server 2012 Share geht wie lokal installiert. Bei Start kommt sofort die Anmeldemaske. Und das dauert vom Server 2019 durchaus 5-10 Sek.
Moin Farddwalling,
Das ist bei den 17 Seiten mittlerweile auch nicht verwunderlich, du musst lediglich den jüngsten Part befolgen.
Vor allem die allerersten Lösungsansätze mit deaktivieren von RSS und RSC sind als Empfehlung nicht mehr gültig.
Wenn es dir um geringe Latenzen und Performance geht, dann ja.
Du musst alle Netzwerkschnittstellen anpassen, vor allem die RSS Defaultkonfiguration ist leider bei allen für den Hintern.
Das betrifft sowohl die Physikalischen Adapter als auch die Virtuellen, sowohl auf den Servern als auch auf den Clients. 🤢🤮
Ich muss gleich weiterflitzen, deshalb fasse ich das wichtigste mal zusammen.
Bei aktuellen Systemen gehe ich folgend vor.
- RSS bleibt an und wird lediglich feinkonfiguriert
Siehe dazu den folgenden Beitrag.
https://community.spiceworks.com/topic/2282473-the-real-disaster-behind- ...
- RSC bleibt auch an, wenn die Hardware NIC das auch unterstützt.
Wenn RSC nicht von der Hardware unterstützt wird, dann muss es vollständig (HW-NIC, vNIC, vSwitch, VM-NIC) abgeschaltet werden.
- VMQ, SRIOV und sämtliches Offloading wird ebenfalls komplett durch die Kette deaktiviert.
Für die Neukonfiguration, sollte das HV-Cluster sicherheitshalber offline sein.
Hmm, evtl. könnte auch eine suboptimale Ansteuerung des Storages dein Problem auch verursachen, aber hierzu benötige ich weitere Angaben über das System.
Welches SAN setzt du ein?
Wie ist es an die HVs angebunden (SAS, FC, iSCSI)?
Beim SAN kann ich dir pauschal nur den Tipp geben, ODX zu deaktivieren und zwar sowohl auf dem HV-Nodes als auch auch bei den VMs selbst.
Wie das geht habe ich hier schon beschrieben.
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
So, jetzt muss ich aber.
Grüsse aus BaWü
Alex
Bei Spiceworks hab ich nicht unbedingt alles verstanden oder in die richtige Reihenfolge gebracht.
Das ist bei den 17 Seiten mittlerweile auch nicht verwunderlich, du musst lediglich den jüngsten Part befolgen.
Vor allem die allerersten Lösungsansätze mit deaktivieren von RSS und RSC sind als Empfehlung nicht mehr gültig.
Man sollte nach wie vor den CongestionProvider von Cubic weg umstellen oder?
Wenn es dir um geringe Latenzen und Performance geht, dann ja.
Wie sieht das mit einem Hyper V Cluster aus? Nur die VM Schnittstelle oder auch die für den Clusterbetrieb und die Shared Volume Umleitung?
Du musst alle Netzwerkschnittstellen anpassen, vor allem die RSS Defaultkonfiguration ist leider bei allen für den Hintern.
Das betrifft sowohl die Physikalischen Adapter als auch die Virtuellen, sowohl auf den Servern als auch auf den Clients. 🤢🤮
Ich muss gleich weiterflitzen, deshalb fasse ich das wichtigste mal zusammen.
Bei aktuellen Systemen gehe ich folgend vor.
- RSS bleibt an und wird lediglich feinkonfiguriert
Siehe dazu den folgenden Beitrag.
https://community.spiceworks.com/topic/2282473-the-real-disaster-behind- ...
- RSC bleibt auch an, wenn die Hardware NIC das auch unterstützt.
Wenn RSC nicht von der Hardware unterstützt wird, dann muss es vollständig (HW-NIC, vNIC, vSwitch, VM-NIC) abgeschaltet werden.
- VMQ, SRIOV und sämtliches Offloading wird ebenfalls komplett durch die Kette deaktiviert.
PS: ach Quark, das ist ja eine allgemeine Einstellung die dann eh für alle Adapter gilt oder? Das heißt aber auch, am besten die Verbindung zum Storage vorher trennen ja?
Für die Neukonfiguration, sollte das HV-Cluster sicherheitshalber offline sein.
PPS: Das kopieren von großen Dateien geht in beiden Richtungen übrigens durchgängig schnell. Aber ähnlich wie bei samet22 wird bei uns ein Programm direkt vom SMB Share gestartet. Von einem Server 2012 Share geht wie lokal installiert. Bei Start kommt sofort die Anmeldemaske. Und das dauert vom Server 2019 durchaus 5-10 Sek.
Hmm, evtl. könnte auch eine suboptimale Ansteuerung des Storages dein Problem auch verursachen, aber hierzu benötige ich weitere Angaben über das System.
Welches SAN setzt du ein?
Wie ist es an die HVs angebunden (SAS, FC, iSCSI)?
Beim SAN kann ich dir pauschal nur den Tipp geben, ODX zu deaktivieren und zwar sowohl auf dem HV-Nodes als auch auch bei den VMs selbst.
Wie das geht habe ich hier schon beschrieben.
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
So, jetzt muss ich aber.
Grüsse aus BaWü
Alex
Hi Alex,
vielen dank für deine schnelle Antwort. Ich werde mal die momentanen Daten sammeln und schauen was z.B. bei RSS hinterlegt ist.
Wir nutzen an dem Standort 2 DL385 Epic Nodes an einer MSA2052 mit je 2x 10Gbit iSCSI Anbindung. DirectAttached.
Die Nodes haben dann je 1x 10Gbit an den Code Switch für die VMs und 1x 10Gbit für das Cluster Netz.
vielen dank für deine schnelle Antwort. Ich werde mal die momentanen Daten sammeln und schauen was z.B. bei RSS hinterlegt ist.
Wir nutzen an dem Standort 2 DL385 Epic Nodes an einer MSA2052 mit je 2x 10Gbit iSCSI Anbindung. DirectAttached.
Die Nodes haben dann je 1x 10Gbit an den Code Switch für die VMs und 1x 10Gbit für das Cluster Netz.
Moin Farddwalling,
Sind deine CSV NTFS oder ReFS formatiert?
Kannst du mir die Ausgabe von get-netadapterrss und get-clustersharedvolumestate von einem der HV-Nodes posten, danke.
Gruss Alex
Wir nutzen an dem Standort 2 DL385 Epic Nodes an einer MSA2052 mit je 2x 10Gbit iSCSI Anbindung. DirectAttached.
Die Nodes haben dann je 1x 10Gbit an den Code Switch für die VMs und 1x 10Gbit für das Cluster Netz.
Die Nodes haben dann je 1x 10Gbit an den Code Switch für die VMs und 1x 10Gbit für das Cluster Netz.
Sind deine CSV NTFS oder ReFS formatiert?
Kannst du mir die Ausgabe von get-netadapterrss und get-clustersharedvolumestate von einem der HV-Nodes posten, danke.
Gruss Alex
Hallo Lieber Alex,
die sind ReFS formatiert. Ich habe testweise die Maschine mit der Freigabe mal direkt auf den Host gezogen um das Storage auszuschließen. Test steht noch aus.
Hier einmal get-clustersharedvolumestate:
Und dann noch get-netadapterrss:
die sind ReFS formatiert. Ich habe testweise die Maschine mit der Freigabe mal direkt auf den Host gezogen um das Storage auszuschließen. Test steht noch aus.
Hier einmal get-clustersharedvolumestate:
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : SSD_Storage
Node : GM-Host-01
StateInfo : Direct
VolumeFriendlyName : Volume2
VolumeName : \\?\Volume{e207bde6-5583-4ff5-b330-af7c7c1101b4}\
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : NotFileSystemRedirected
Name : SSD_Storage
Node : GM-Host-02
StateInfo : Direct
VolumeFriendlyName : Volume2
VolumeName : \\?\Volume{e207bde6-5583-4ff5-b330-af7c7c1101b4}\
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : FileSystemReFs
Name : Storage
Node : GM-Host-01
StateInfo : FileSystemRedirected
VolumeFriendlyName : Volume1
VolumeName : \\?\Volume{a00b8662-71ca-428b-95d2-df9440738c51}\
BlockRedirectedIOReason : NotBlockRedirected
FileSystemRedirectedIOReason : FileSystemReFs
Name : Storage
Node : GM-Host-02
StateInfo : FileSystemRedirected
VolumeFriendlyName : Volume1
VolumeName : \\?\Volume{a00b8662-71ca-428b-95d2-df9440738c51}\Und dann noch get-netadapterrss:
Name : phy-pcie1-port1-Cluster
InterfaceDescription : HPE Ethernet 10/25Gb 2-port 640SFP28 Adapter #2
Enabled : True
NumberOfReceiveQueues : 8
Profile : Closest
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:30
MaxProcessors : 8
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0
0:16/0 0:18/0 0:20/0 0:22/0 0:24/0 0:26/0 0:28/0 0:30/0
IndirectionTable: [Group:Number] : 0:0 0:2 0:4 0:6 0:8 0:10 0:0 0:2
0:4 0:6 0:8 0:10 0:0 0:2 0:4 0:6
0:8 0:10 0:0 0:2 0:4 0:6 0:8 0:10
0:0 0:2 0:4 0:6 0:8 0:10 0:0 0:2
0:4 0:6 0:8 0:10 0:0 0:2 0:4 0:6
0:8 0:10 0:0 0:2 0:4 0:6 0:8 0:10
0:0 0:2 0:4 0:6 0:8 0:10 0:0 0:2
0:4 0:6 0:8 0:10 0:0 0:2 0:4 0:6
0:8 0:10 0:0 0:2 0:4 0:6 0:8 0:10
0:0 0:2 0:4 0:6 0:8 0:10 0:0 0:2
0:4 0:6 0:8 0:10 0:0 0:2 0:4 0:6
0:8 0:10 0:0 0:2 0:4 0:6 0:8 0:10
0:0 0:2 0:4 0:6 0:8 0:10 0:0 0:2
0:4 0:6 0:8 0:10 0:0 0:2 0:4 0:6
0:8 0:10 0:0 0:2 0:4 0:6 0:8 0:10
0:0 0:2 0:4 0:6 0:8 0:10 0:0 0:2
Name : phy-pcie3-port1-VM
InterfaceDescription : HPE Ethernet 10/25Gb 2-port 640SFP28 Adapter
Enabled : True
NumberOfReceiveQueues : 8
Profile : Closest
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:30
MaxProcessors : 8
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0
0:16/0 0:18/0 0:20/0 0:22/0 0:24/0 0:26/0 0:28/0 0:30/0
IndirectionTable: [Group:Number] : 0:0 0:2 0:4 0:6 0:8 0:10 0:12 0:14
0:0 0:2 0:4 0:6 0:8 0:10 0:12 0:14
Name : LOM 1 Port 1 Management
InterfaceDescription : HPE Ethernet 1Gb 4-port 366FLR Adapter #2
Enabled : True
NumberOfReceiveQueues : 2
Profile : NUMAStatic
BaseProcessor: [Group:Number] : :0
MaxProcessor: [Group:Number] : :63
MaxProcessors : 8
RssProcessorArray: [Group:Number/NUMA Distance] :
IndirectionTable: [Group:Number] :
Name : Embedded FlexibleLOM 1 Port 4
InterfaceDescription : HPE Ethernet 1Gb 4-port 366FLR Adapter
Enabled : True
NumberOfReceiveQueues : 2
Profile : NUMAStatic
BaseProcessor: [Group:Number] : :0
MaxProcessor: [Group:Number] : :63
MaxProcessors : 8
RssProcessorArray: [Group:Number/NUMA Distance] :
IndirectionTable: [Group:Number] :
Name : phy-pcie3-port2-Storage2
InterfaceDescription : HPE Ethernet 10/25Gb 2-port 640SFP28 Adapter #4
Enabled : True
NumberOfReceiveQueues : 8
Profile : Closest
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:30
MaxProcessors : 8
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0
0:16/0 0:18/0 0:20/0 0:22/0 0:24/0 0:26/0 0:28/0 0:30/0
IndirectionTable: [Group:Number] : 0:22 0:24 0:26 0:28 0:30 0:22 0:24 0:26
0:28 0:30 0:22 0:24 0:26 0:28 0:30 0:22
0:24 0:26 0:28 0:30 0:22 0:24 0:26 0:28
0:30 0:22 0:24 0:26 0:28 0:30 0:22 0:24
0:26 0:28 0:30 0:22 0:24 0:26 0:28 0:30
0:22 0:24 0:26 0:28 0:30 0:22 0:24 0:26
0:28 0:30 0:22 0:24 0:26 0:28 0:30 0:22
0:24 0:26 0:28 0:30 0:22 0:24 0:26 0:28
0:30 0:22 0:24 0:26 0:28 0:30 0:22 0:24
0:26 0:28 0:30 0:22 0:24 0:26 0:28 0:30
0:22 0:24 0:26 0:28 0:30 0:22 0:24 0:26
0:28 0:30 0:22 0:24 0:26 0:28 0:30 0:22
0:24 0:26 0:28 0:30 0:22 0:24 0:26 0:28
0:30 0:22 0:24 0:26 0:28 0:30 0:22 0:24
0:26 0:28 0:30 0:22 0:24 0:26 0:28 0:30
0:22 0:24 0:26 0:28 0:30 0:22 0:24 0:26
Name : Embedded FlexibleLOM 1 Port 3
InterfaceDescription : HPE Ethernet 1Gb 4-port 366FLR Adapter #4
Enabled : True
NumberOfReceiveQueues : 2
Profile : NUMAStatic
BaseProcessor: [Group:Number] : :0
MaxProcessor: [Group:Number] : :63
MaxProcessors : 8
RssProcessorArray: [Group:Number/NUMA Distance] :
IndirectionTable: [Group:Number] :
Name : LOM 1 Port 2 Cluster
InterfaceDescription : HPE Ethernet 1Gb 4-port 366FLR Adapter #3
Enabled : True
NumberOfReceiveQueues : 2
Profile : NUMAStatic
BaseProcessor: [Group:Number] : :0
MaxProcessor: [Group:Number] : :63
MaxProcessors : 8
RssProcessorArray: [Group:Number/NUMA Distance] :
IndirectionTable: [Group:Number] :
Name : phy-pcie1-port2-Storage1
InterfaceDescription : HPE Ethernet 10/25Gb 2-port 640SFP28 Adapter #3
Enabled : True
NumberOfReceiveQueues : 8
Profile : Closest
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:30
MaxProcessors : 8
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0
0:16/0 0:18/0 0:20/0 0:22/0 0:24/0 0:26/0 0:28/0 0:30/0
IndirectionTable: [Group:Number] : 0:12 0:14 0:16 0:18 0:20 0:12 0:14 0:16
0:18 0:20 0:12 0:14 0:16 0:18 0:20 0:12
0:14 0:16 0:18 0:20 0:12 0:14 0:16 0:18
0:20 0:12 0:14 0:16 0:18 0:20 0:12 0:14
0:16 0:18 0:20 0:12 0:14 0:16 0:18 0:20
0:12 0:14 0:16 0:18 0:20 0:12 0:14 0:16
0:18 0:20 0:12 0:14 0:16 0:18 0:20 0:12
0:14 0:16 0:18 0:20 0:12 0:14 0:16 0:18
0:20 0:12 0:14 0:16 0:18 0:20 0:12 0:14
0:16 0:18 0:20 0:12 0:14 0:16 0:18 0:20
0:12 0:14 0:16 0:18 0:20 0:12 0:14 0:16
0:18 0:20 0:12 0:14 0:16 0:18 0:20 0:12
0:14 0:16 0:18 0:20 0:12 0:14 0:16 0:18
0:20 0:12 0:14 0:16 0:18 0:20 0:12 0:14
0:16 0:18 0:20 0:12 0:14 0:16 0:18 0:20
0:12 0:14 0:16 0:18 0:20 0:12 0:14 0:16
Ich habe jetzt grade mal den Programmstart getestet. Es macht keinen Unterschied, ob die VM auf dem Storage oder direkt auf eine SSD des Hosts liegt.
Moin Farddwalling,
Bist du dir ganz sicher, dass beide CSV's mit ReFS formatiert sind?
Das kann ich mir insbesondere bei der mit dem Namen "SSD_Storage" kaum vorstellen, die läuft bei dir im Direct Mode, was eher für eine NTFS Formatierung sprechen würde. Ansonsten bist du der erste, bei dem ein ReFS formatiertes CVS im Direct Mode läuft.
Ich will es aber keineswegs ausschliessen, da ich genau wegen diesem Thema gerade einen grösseren Support Call bei Microsoft offen habe.
Kannst du das bitte nochmal genauer verifizieren, danke.
Bez. des Storages kann ich dir an dieser Stelle noch den Tip geben, unbedingt ODX auf deinen HV-Nodes und auch auf den VMs >2012R2 zu deaktivieren.
Das geht ganz einfach mit dem folgenden Power-Shell Befehl.
Damit die Änderung greift, müssen die entsprechenden Maschinen jedoch neu gebootet werden.
Zum Rest (Netzwerk) komme ich noch später.
Grüsse aus BaWü
Alex
Zitat von @farddwalling:
Hallo Lieber Alex,
die sind ReFS formatiert. Ich habe testweise die Maschine mit der Freigabe mal direkt auf den Host gezogen um das Storage auszuschließen. Test steht noch aus.
Hier einmal get-clustersharedvolumestate:
Hallo Lieber Alex,
die sind ReFS formatiert. Ich habe testweise die Maschine mit der Freigabe mal direkt auf den Host gezogen um das Storage auszuschließen. Test steht noch aus.
Hier einmal get-clustersharedvolumestate:
> BlockRedirectedIOReason : NotBlockRedirected
> FileSystemRedirectedIOReason : NotFileSystemRedirected
> Name : SSD_Storage
> Node : GM-Host-01
> StateInfo : Direct
> VolumeFriendlyName : Volume2
> VolumeName : \\?\Volume{e207bde6-5583-4ff5-b330-af7c7c1101b4}\
>
> BlockRedirectedIOReason : NotBlockRedirected
> FileSystemRedirectedIOReason : NotFileSystemRedirected
> Name : SSD_Storage
> Node : GM-Host-02
> StateInfo : Direct
> VolumeFriendlyName : Volume2
> VolumeName : \\?\Volume{e207bde6-5583-4ff5-b330-af7c7c1101b4}\
>
> BlockRedirectedIOReason : NotBlockRedirected
> FileSystemRedirectedIOReason : FileSystemReFs
> Name : Storage
> Node : GM-Host-01
> StateInfo : FileSystemRedirected
> VolumeFriendlyName : Volume1
> VolumeName : \\?\Volume{a00b8662-71ca-428b-95d2-df9440738c51}\
>
> BlockRedirectedIOReason : NotBlockRedirected
> FileSystemRedirectedIOReason : FileSystemReFs
> Name : Storage
> Node : GM-Host-02
> StateInfo : FileSystemRedirected
> VolumeFriendlyName : Volume1
> VolumeName : \\?\Volume{a00b8662-71ca-428b-95d2-df9440738c51}\
> Bist du dir ganz sicher, dass beide CSV's mit ReFS formatiert sind?
Das kann ich mir insbesondere bei der mit dem Namen "SSD_Storage" kaum vorstellen, die läuft bei dir im Direct Mode, was eher für eine NTFS Formatierung sprechen würde. Ansonsten bist du der erste, bei dem ein ReFS formatiertes CVS im Direct Mode läuft.
Ich will es aber keineswegs ausschliessen, da ich genau wegen diesem Thema gerade einen grösseren Support Call bei Microsoft offen habe.
Kannst du das bitte nochmal genauer verifizieren, danke.
Bez. des Storages kann ich dir an dieser Stelle noch den Tip geben, unbedingt ODX auf deinen HV-Nodes und auch auf den VMs >2012R2 zu deaktivieren.
Das geht ganz einfach mit dem folgenden Power-Shell Befehl.
Set-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name "FilterSupportedFeaturesMode" -Value 1 Damit die Änderung greift, müssen die entsprechenden Maschinen jedoch neu gebootet werden.
Zum Rest (Netzwerk) komme ich noch später.
Grüsse aus BaWü
Alex
Moin Farddwalling,
kleine Zwischenfrage, welche CPUs stecken bei dir in den Nodes?
Gruss Alex
kleine Zwischenfrage, welche CPUs stecken bei dir in den Nodes?
Gruss Alex
Mh, da könntest du tatsächlich Recht haben. Hatte nur das filesSystemrefs bei dem Storage gesehen...
Das ssd_storage hatten wir testweise dann nachträglich gemacht.
Das ssd_storage hatten wir testweise dann nachträglich gemacht.
Das sind Epyc 7302 16-Core CPUs. 1x pro Node.
Moin Farddwalling,
dein RSS Konfig ist für meinen Geschmack zwar noch nicht optimal, aber auch nicht gänzlich falsch.
Hast du schon mal versucht eine Windows 10 VM aufzusetzten und zu schauen, wie sich das ganze mit einem Virtuellen Client verhält?
Wenn die Applikation auf dem Server schnell genug startet, dann ist das Storage für ein inperformantes Starten am Client meistens nicht verantwortlich.
Sind deine Clients Windows 10?
Wenn ja, dann versuch mal auch auf einem Client CUBIC gegen DCTCP zu tauschen.
Grüsse aus BaWü
Alex
dein RSS Konfig ist für meinen Geschmack zwar noch nicht optimal, aber auch nicht gänzlich falsch.
Hast du schon mal versucht eine Windows 10 VM aufzusetzten und zu schauen, wie sich das ganze mit einem Virtuellen Client verhält?
Wenn die Applikation auf dem Server schnell genug startet, dann ist das Storage für ein inperformantes Starten am Client meistens nicht verantwortlich.
Sind deine Clients Windows 10?
Wenn ja, dann versuch mal auch auf einem Client CUBIC gegen DCTCP zu tauschen.
netsh int tcp set supplemental template=internet congestionprovider=DCTCP
netsh int tcp set supplemental template=internetcustom congestionprovider=DCTCP
netsh int tcp set supplemental template=Datacenter congestionprovider=DCTCP
netsh int tcp set supplemental template=Datacentercustom congestionprovider=DCTCPGrüsse aus BaWü
Alex
Da bin ich ja schon Mal beruhigt.
Also wir haben ein Windows 10 als VM, das läuft an sich aber schon Mau und die Applikation braucht ewig zum starten, also ähnlich den echten Clients. Auf einem 2019 Terminalserver ist es schon nen tacken langsamer. Und von den echten Clients dann nochmal langsamer.
Ich teste auf einem Client das umstellen Mal.
Und sonst halt auf dem Host und in der 2019 VM?
Also wir haben ein Windows 10 als VM, das läuft an sich aber schon Mau und die Applikation braucht ewig zum starten, also ähnlich den echten Clients. Auf einem 2019 Terminalserver ist es schon nen tacken langsamer. Und von den echten Clients dann nochmal langsamer.
Ich teste auf einem Client das umstellen Mal.
Und sonst halt auf dem Host und in der 2019 VM?
Moin Farddwalling,
so wie ich sehe, unterstützt deine Adapter kein RSC.
https://h20195.www2.hpe.com/v2/GetDocument.aspx?docname=a00047733enw
Daher solltest du dieses bei den betreffenden vSwitches auch unbedingt deaktivieren.
Grüsse aus BaWü
Alex
P.S.
VMQ und SRIOV würde ich ebenfalls vorerst deaktivieren.
P.S.P.S.
mit kannst du den RSC Status der NICs im Vorfeld abfragen.
Und sonst halt auf dem Host und in der 2019 VM?
so wie ich sehe, unterstützt deine Adapter kein RSC.
https://h20195.www2.hpe.com/v2/GetDocument.aspx?docname=a00047733enw
Daher solltest du dieses bei den betreffenden vSwitches auch unbedingt deaktivieren.
Set-VMSwitch -Name "vSwitch_Name" -EnableSoftwareRsc $false Grüsse aus BaWü
Alex
P.S.
VMQ und SRIOV würde ich ebenfalls vorerst deaktivieren.
P.S.P.S.
mit
Get-NetAdapterRsc
Moin Alex,
das wirft mir das System mit Get-NetAdapterRsc raus:
VG
Christian
das wirft mir das System mit Get-NetAdapterRsc raus:
Name IPv4Enabled IPv6Enabled IPv4Operational IPv6Operational IPv4FailureReason IPv6FailureR
State State eason
---- ----------- ----------- --------------- --------------- ----------------- ------------
phy-pcie1-port1-Cluster True True True True NoFailure NoFailure
phy-pcie3-port1-VM True True False False NetOffloadGlob... NetOffloa...
phy-pcie3-port2-Storage2 True True True True NoFailure NoFailure
phy-pcie1-port2-Storage1 True True True True NoFailure NoFailureVG
Christian
Moin Christian,
Ja, hast recht, nach der Doku können die Adapter das auch.
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docI ...
Ja, die netten HPE Dokus, die haben mich schon bei anderen Projekten ganz kirre gemacht.
Ich denke, wir sollten noch ein paar andere Möglichkeiten für dein Problem in Betracht ziehen.
Welche AV Lösung hast du im Einsatz?
Ist auf dem Applikationsserver eine Dritthersteller AV aktiviert?
Hast du mal versucht auf dem Client sowohl die AV als auch SmartScreen & Co zu deaktivieren?
Ist die Windows Firewall aktiviert?
Auch die Energieeinstellungen sind bei so was sehr relevant, bitte auf allen betroffenen Maschinen (HV-Node's, VM's, Clients) auf "Hochleistung"
stellen.
Grüsse aus BaWü
Alex
Zitat von @farddwalling:
Moin Alex,
das wirft mir das System mit Get-NetAdapterRsc raus:
Moin Alex,
das wirft mir das System mit Get-NetAdapterRsc raus:
> Name IPv4Enabled IPv6Enabled IPv4Operational IPv6Operational IPv4FailureReason IPv6FailureR
> State State eason
> ---- ----------- ----------- --------------- --------------- ----------------- ------------
> phy-pcie1-port1-Cluster True True True True NoFailure NoFailure
> phy-pcie3-port1-VM True True False False NetOffloadGlob... NetOffloa...
> phy-pcie3-port2-Storage2 True True True True NoFailure NoFailure
> phy-pcie1-port2-Storage1 True True True True NoFailure NoFailure
> Ja, hast recht, nach der Doku können die Adapter das auch.
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docI ...
Ja, die netten HPE Dokus, die haben mich schon bei anderen Projekten ganz kirre gemacht.
Ich denke, wir sollten noch ein paar andere Möglichkeiten für dein Problem in Betracht ziehen.
Welche AV Lösung hast du im Einsatz?
Ist auf dem Applikationsserver eine Dritthersteller AV aktiviert?
Hast du mal versucht auf dem Client sowohl die AV als auch SmartScreen & Co zu deaktivieren?
Ist die Windows Firewall aktiviert?
Auch die Energieeinstellungen sind bei so was sehr relevant, bitte auf allen betroffenen Maschinen (HV-Node's, VM's, Clients) auf "Hochleistung"
stellen.
Grüsse aus BaWü
Alex
Da ärgere ich mich ab und an bei HPE auch tierisch drüber. Auch deren Software Updates und Firmware Philosophie ist so überhaupt nicht meine.
Als AV setzen wir Trend Micro Apex One ein. Auf dem Applicationserver ist der aber nicht aktiv. Auf den Clients haben wir testweise auch schon mal deinstalliert.
Windows Firewall ist aktiv.
Das einzige was auch noch groß anders zu früher, oder auch zu dem Testserver mit der "schnellen" Freigabe ist, ist das Netzwerk. Die Server sind in einem neuen Subnetz. Layer 3 Switch ist ein Aruba 2930F.
Ich könnte den Testserver auch mal in dieses Subnetz schieben und testen ob es daran liegt.
PS: So, den Testserver in das Subnetz verschoben. Start bleibt schnell. Also vom 2012R2 ist es fix, vom 2019 VM langsam.
Als AV setzen wir Trend Micro Apex One ein. Auf dem Applicationserver ist der aber nicht aktiv. Auf den Clients haben wir testweise auch schon mal deinstalliert.
Windows Firewall ist aktiv.
Das einzige was auch noch groß anders zu früher, oder auch zu dem Testserver mit der "schnellen" Freigabe ist, ist das Netzwerk. Die Server sind in einem neuen Subnetz. Layer 3 Switch ist ein Aruba 2930F.
Ich könnte den Testserver auch mal in dieses Subnetz schieben und testen ob es daran liegt.
PS: So, den Testserver in das Subnetz verschoben. Start bleibt schnell. Also vom 2012R2 ist es fix, vom 2019 VM langsam.
Moin Christian,
besteht die Möglichkeit, dass ich mir die Umgebung mal per Teamviewer anschauen kann?
Wenn ja, dann schicke ich dir meine Kontaktdaten per PN.
Grüsse aus BaWü
Alex
besteht die Möglichkeit, dass ich mir die Umgebung mal per Teamviewer anschauen kann?
Wenn ja, dann schicke ich dir meine Kontaktdaten per PN.
Grüsse aus BaWü
Alex
Hi Alex,
das kriegen wir bestimmt mal hin.
Ich habe jetzt nochmal insofern getestet, das ich die Applikation auf eine Server 2012 VM gelegt und freigegeben habe. Auf dem gleichen Host, gleiche sonstige Umgebung.
Dort startet die Applikation deutlich fixer. Es scheint also doch wirklich so, das Server 2019 das Problem ist. Nicht direkt die VM, denn auf einer anderen Server 2019 VM dauert es auch lange.
VG
Christian
das kriegen wir bestimmt mal hin.
Ich habe jetzt nochmal insofern getestet, das ich die Applikation auf eine Server 2012 VM gelegt und freigegeben habe. Auf dem gleichen Host, gleiche sonstige Umgebung.
Dort startet die Applikation deutlich fixer. Es scheint also doch wirklich so, das Server 2019 das Problem ist. Nicht direkt die VM, denn auf einer anderen Server 2019 VM dauert es auch lange.
VG
Christian
Moin Christian,
Der Server 2019 hat auch einen Haufen Schnickschnack mehr aktiv als der Server 2012R2 und irgend eins davon kommt dir nun in die Quere.
Zum glück lässt sich der meiste Schnickschnack abschalten, wir müssen nur noch rausfinden, um welchen es sich bei dir genau handelt.
Gruss Alex
Zitat von @farddwalling:
Hi Alex,
das kriegen wir bestimmt mal hin.
Ich habe jetzt nochmal insofern getestet, das ich die Applikation auf eine Server 2012 VM gelegt und freigegeben habe. Auf dem gleichen Host, gleiche sonstige Umgebung.
Dort startet die Applikation deutlich fixer. Es scheint also doch wirklich so, das Server 2019 das Problem ist. Nicht direkt die VM, denn auf einer anderen Server 2019 VM dauert es auch lange.
Hi Alex,
das kriegen wir bestimmt mal hin.
Ich habe jetzt nochmal insofern getestet, das ich die Applikation auf eine Server 2012 VM gelegt und freigegeben habe. Auf dem gleichen Host, gleiche sonstige Umgebung.
Dort startet die Applikation deutlich fixer. Es scheint also doch wirklich so, das Server 2019 das Problem ist. Nicht direkt die VM, denn auf einer anderen Server 2019 VM dauert es auch lange.
Der Server 2019 hat auch einen Haufen Schnickschnack mehr aktiv als der Server 2012R2 und irgend eins davon kommt dir nun in die Quere.
Zum glück lässt sich der meiste Schnickschnack abschalten, wir müssen nur noch rausfinden, um welchen es sich bei dir genau handelt.
Gruss Alex
Hi Alex,
ich habe jetzt an einer Test VM den CongestionProvider CTCP eingestellt und die VM neugestartet. Mein erster Test würde mir einen deutlich schnelleren Programmstart bescheinigen.
Ich teste das jetzt nochmal mit den Kollegen vor Ort und würde dann wahrscheinlich dazu übergeben, das an allen 2019er Systemen durchzuführen.
ich habe jetzt an einer Test VM den CongestionProvider CTCP eingestellt und die VM neugestartet. Mein erster Test würde mir einen deutlich schnelleren Programmstart bescheinigen.
Ich teste das jetzt nochmal mit den Kollegen vor Ort und würde dann wahrscheinlich dazu übergeben, das an allen 2019er Systemen durchzuführen.
Moin Christian,
Bitte nicht CTCP benutzen, sondern DCTCP.
Auf einem Server 2019 am besten das folgende ausführen.
(als Administrator ausführen)
Bei Windows 10 funktioniert das folgende Script.
(als Administrator ausführen)
Grüsse aus BaWü
Alex
ich habe jetzt an einer Test VM den CongestionProvider CTCP eingestellt und die VM neugestartet. Mein erster Test würde mir einen deutlich schnelleren Programmstart bescheinigen.
Bitte nicht CTCP benutzen, sondern DCTCP.
Auf einem Server 2019 am besten das folgende ausführen.
(als Administrator ausführen)
#NATIVE2019, HV2019, VM2019
#Get-NetTCPSetting | ft -AutoSize
Set-NetTCPSetting -SettingName "InternetCustom" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "DatacenterCustom" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "Datacenter" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "Internet" -CongestionProvider DCTCP Bei Windows 10 funktioniert das folgende Script.
(als Administrator ausführen)
netsh int tcp set supplemental template=internet congestionprovider=DCTCP
netsh int tcp set supplemental template=internetcustom congestionprovider=DCTCP
netsh int tcp set supplemental template=Datacenter congestionprovider=DCTCP
netsh int tcp set supplemental template=Datacentercustom congestionprovider=DCTCPGrüsse aus BaWü
Alex
Hey Alex,
sorry, falscher Befehle copy & paste.
Ist auf DCTCP umgestellt.
Bei den Windows 10 Clients hatte sich nichts geändert dadurch. oder sollten immer beide Seiten das "richtige" haben?
Und auf dem Host habe ich das natürlich auch noch nicht.
VG
Christian
PS: Auf dem Server, wo ich den CongestionProvider geändert habe, gibt mir get-netadapterrss folgendes jetzt aus:
Auf dem noch nicht geänderten:
PPS: Und noch eine Nachfrage, gibts das Problem nur bei Server 2019 VMs auf einem Hyper V Host? oder tritt das auch unter vmWare auf?
sorry, falscher Befehle copy & paste.
Ist auf DCTCP umgestellt.
Bei den Windows 10 Clients hatte sich nichts geändert dadurch. oder sollten immer beide Seiten das "richtige" haben?
Und auf dem Host habe ich das natürlich auch noch nicht.
VG
Christian
PS: Auf dem Server, wo ich den CongestionProvider geändert habe, gibt mir get-netadapterrss folgendes jetzt aus:
Name : Ethernet
InterfaceDescription : Microsoft Hyper-V-Netzwerkadapter
Enabled : False
NumberOfReceiveQueues : 0
Profile : NUMAStatic
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:2
MaxProcessors : 2
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0
IndirectionTable: [Group:Number] :Auf dem noch nicht geänderten:
Name : Ethernet 2
InterfaceDescription : Microsoft Hyper-V Network Adapter #2
Enabled : True
NumberOfReceiveQueues : 1
Profile : NUMAStatic
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:0
MaxProcessors : 1
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0
IndirectionTable: [Group:Number] : 0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0
0:0 0:0 0:0 0:0 0:0 0:0 0:0 0:0PPS: Und noch eine Nachfrage, gibts das Problem nur bei Server 2019 VMs auf einem Hyper V Host? oder tritt das auch unter vmWare auf?
Moin Christian,
In diesem Fall ist es von Vorteil durchgängig dasselbe zu benutzen
Entweder ist auf diesem Server RSS auf dem TCP Stack deaktiviert worden oder über den Treiber der vNIC
Feuer auf diesem Server bitte mal den folgenden Befehl ab und starte die Kiste neu.
Wie sieht das ganze danach aus?
Hast du ODX auf den HV Nodes und dem VMs schon deaktiviert?
Bei VMware gibt es zum Teil dieselben zum Teil ganz andere Probleme.
Grüsse aus BaWü
Alex
Bei den Windows 10 Clients hatte sich nichts geändert dadurch. oder sollten immer beide Seiten das "richtige" haben?
Und auf dem Host habe ich das natürlich auch noch nicht.
Und auf dem Host habe ich das natürlich auch noch nicht.
In diesem Fall ist es von Vorteil durchgängig dasselbe zu benutzen
PS: Auf dem Server, wo ich den CongestionProvider geändert habe, gibt mir get-netadapterrss folgendes jetzt aus:
Name : Ethernet
> InterfaceDescription : Microsoft Hyper-V-Netzwerkadapter
> Enabled : False
> NumberOfReceiveQueues : 0
> Profile : NUMAStatic
> BaseProcessor: [Group:Number] : 0:0
> MaxProcessor: [Group:Number] : 0:2
> MaxProcessors : 2
> RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0
> IndirectionTable: [Group:Number] :Entweder ist auf diesem Server RSS auf dem TCP Stack deaktiviert worden oder über den Treiber der vNIC
Feuer auf diesem Server bitte mal den folgenden Befehl ab und starte die Kiste neu.
netsh int tcp set global RSS=Enabled
netsh int tcp set global RSC=Enabled
Get-NetAdapter -Name "Ethernet" | Set-NetAdapterAdvancedProperty -RegistryKeyword "*MaxRssProcessors" -RegistryValue "2" -NoRestart
Get-NetAdapter -Name "Ethernet" | Set-NetAdapterAdvancedProperty -RegistryKeyword "*NumRSSQueues" -RegistryValue "2" -NoRestart
Get-NetAdapter -Name "Ethernet" | Set-NetAdapterAdvancedProperty -RegistryKeyword "*RssBaseProcNumber" -RegistryValue "0" -NoRestart
Get-NetAdapter -Name "Ethernet" | Set-NetAdapterAdvancedProperty -RegistryKeyword "*RSSProfile" -RegistryValue "1" -NoRestart
Get-NetAdapter -Name "Ethernet" | Set-NetAdapterAdvancedProperty -RegistryKeyword "*RssMaxProcNumber" -RegistryValue "2" -NoRestart
Get-NetAdapter -Name "Ethernet" | New-NetAdapterAdvancedProperty -RegistryKeyword "*RssBaseProcGroup" -RegistryValue "0" -NoRestart
Get-NetAdapter -Name "Ethernet" | New-NetAdapterAdvancedProperty -RegistryKeyword "*RssMaxProcGroup" -RegistryValue "0" -NoRestart
Get-NetAdapter -Name "Ethernet" | New-NetAdapterAdvancedProperty -RegistryKeyword "*NumaNodeId" -RegistryValue "0" -NoRestart
Get-NetAdapter -Name "Ethernet" | Set-NetAdapterAdvancedProperty -RegistryKeyword "*RSS" -RegistryValue "1" -NoRestart Wie sieht das ganze danach aus?
Hast du ODX auf den HV Nodes und dem VMs schon deaktiviert?
PPS: Und noch eine Nachfrage, gibts das Problem nur bei Server 2019 VMs auf einem Hyper V Host? oder tritt das auch unter vmWare auf?
Bei VMware gibt es zum Teil dieselben zum Teil ganz andere Probleme.
Grüsse aus BaWü
Alex
Hi Alex,
nein ODX hab ich noch nicht angefasst. Müsste erstmal schauen, wann ich die Nodes neustarten kann. Es sind nicht alle VMs hochverfügbar. 🙄
RSS und RSC hab ich mal enabled und starte gerade neu.
Und auf vmWare könnte ich aber auch den CongestionProvider bei gezicke erstmal umstellen und schauen ob es besser ist?
nein ODX hab ich noch nicht angefasst. Müsste erstmal schauen, wann ich die Nodes neustarten kann. Es sind nicht alle VMs hochverfügbar. 🙄
RSS und RSC hab ich mal enabled und starte gerade neu.
Und auf vmWare könnte ich aber auch den CongestionProvider bei gezicke erstmal umstellen und schauen ob es besser ist?
Moin Christian,
Wie sieht es nun nach dem Neustart aus?
Jetzt verwirrst du mich etwas, was meinst du mit VMware und CongestionProvider.
Meinst du eine Windows VM die auf einem ESXi läuft oder den ESXi selbst?
Beim letzteren kann man diesbezüglich glaube ich nichts konfigurieren, aber zu 100% weis ich das jetzt auch nicht.
In einer VMware VM würde ich ODX aber auch deaktivieren.
Grüsse aus BaWü
Alex
nein ODX hab ich noch nicht angefasst. Müsste erstmal schauen, wann ich die Nodes neustarten kann. Es sind nicht alle VMs hochverfügbar. 🙄
Du kannst und solltest ODX nicht nur auf den Nodes sondern auch auf den VMs deaktivieren, ich schalte es mittlerweile pauschal auf allem >= 2012R2 ab.RSS und RSC hab ich mal enabled und starte gerade neu.
Wie sieht es nun nach dem Neustart aus?
Und auf vmWare könnte ich aber auch den CongestionProvider bei gezicke erstmal umstellen und schauen ob es besser ist?
Jetzt verwirrst du mich etwas, was meinst du mit VMware und CongestionProvider.
Meinst du eine Windows VM die auf einem ESXi läuft oder den ESXi selbst?
Beim letzteren kann man diesbezüglich glaube ich nichts konfigurieren, aber zu 100% weis ich das jetzt auch nicht.
In einer VMware VM würde ich ODX aber auch deaktivieren.
Grüsse aus BaWü
Alex
Hi Alex,
aaach ist aber auch alles ein durcheinander hier.
Also ich habe bis jetzt nur auf den zwei Server 2019 VMs den CongestionProvider auf DCTCP zurückgeändert. Auf dem Testserver ist die Startperformance der Applikation über die SMB Freigabe deutlich schneller geworden. Auf dem Produktiv-Server hat sich scheinbar nicht viel geändert.
Auf dem Testserver, wo das RSS auf False stand, steht jetzt:
Das hat wohl geklappt. Wobei das scheinbar eh keine Auswirkung hatte. Zumindest keine Direkte, die man hätte spüren können.
ODX habe ich noch nichts angepasst. Ist das schädlich wenn das läuft? Ich dachte damit findet ggfs. ein verschieben von Daten direkt auf dem Storage statt, statt erst über den Host zu gehen, oder nicht?
Bzgl. vmWare ging es mit da um die Server 2019 VMs, ob es da auch so Performance Probleme mit dem CUBIC gibt.
aaach ist aber auch alles ein durcheinander hier.
Also ich habe bis jetzt nur auf den zwei Server 2019 VMs den CongestionProvider auf DCTCP zurückgeändert. Auf dem Testserver ist die Startperformance der Applikation über die SMB Freigabe deutlich schneller geworden. Auf dem Produktiv-Server hat sich scheinbar nicht viel geändert.
Auf dem Testserver, wo das RSS auf False stand, steht jetzt:
Name : Ethernet
InterfaceDescription : Microsoft Hyper-V-Netzwerkadapter
Enabled : True
NumberOfReceiveQueues : 2
Profile : Closest
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:2
MaxProcessors : 2
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0
IndirectionTable: [Group:Number] : 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2Das hat wohl geklappt. Wobei das scheinbar eh keine Auswirkung hatte. Zumindest keine Direkte, die man hätte spüren können.
ODX habe ich noch nichts angepasst. Ist das schädlich wenn das läuft? Ich dachte damit findet ggfs. ein verschieben von Daten direkt auf dem Storage statt, statt erst über den Host zu gehen, oder nicht?
Bzgl. vmWare ging es mit da um die Server 2019 VMs, ob es da auch so Performance Probleme mit dem CUBIC gibt.
Moin Christian,
Stück für Stück, wie du selber siehst, geht es ja schon in die richtige Richtung. 😀
Die Unterschied merkst du meistens dann, wenn du die Bandbreite der vNICs vollständig auslasten möchtest, das wird dir mit einer normalen Anwendung aber kaum gelingen. Ferner kann RSS bei einer falschen Konfiguration auch ausbremsen, aber das war bei dir, bei dieser VM ja gar nicht der Fall. Hier war das RSS lediglich ausgeschaltet, somit war die NIC zwar CPU technisch auf einen bestimmten Durchsatz limitiert, dieses Limit liegt aber meistens weit über 1G und ist somit für die meisten Clientanwendungen eh irrelevant, da kaum ein Client mit > 1G angebunden ist. Es gibt so ein Aberglauben, dass eine NIC ohne RSS nur 4G schaffen kann, aber das stimmt stand heute absolut nicht mehr. Habe dazu auch schon mal den folgenden Beitrag bei Spiceworks geschrieben.
https://community.spiceworks.com/topic/2269972-weird-4gbit-s-nic-limit-w ...
Wenn dein Storage selbst ODX nicht unterstützt, dann ist es im Sinne der Performance durchaus schädlich.
Zu diesem Thema werde ich in Kürze einen eigenständigen Artikel verfassen.
Ich kann dir diese Frage aus persönlicher Erfahrung nicht beantworten. Wir haben nur noch einen Kunden mit VMware im Bestand, dieser hat jodoch noch keine 2019er VM am laufen. Wenn ich jedoch dem Feedback von den Usern aus dem Schwesterpost bei Spiceworks vertrauen kann, dann definitiv ja.
Grüsse aus BaWü
Alex
Also ich habe bis jetzt nur auf den zwei Server 2019 VMs den CongestionProvider auf DCTCP zurückgeändert. Auf dem Testserver ist die Startperformance der Applikation über die SMB Freigabe deutlich schneller geworden. Auf dem Produktiv-Server hat sich scheinbar nicht viel geändert.
Stück für Stück, wie du selber siehst, geht es ja schon in die richtige Richtung. 😀
Auf dem Testserver, wo das RSS auf False stand, steht jetzt:
Das hat wohl geklappt. Wobei das scheinbar eh keine Auswirkung hatte. Zumindest keine Direkte, die man hätte spüren können.
Name : Ethernet
> InterfaceDescription : Microsoft Hyper-V-Netzwerkadapter
> Enabled : True
> NumberOfReceiveQueues : 2
> Profile : Closest
> BaseProcessor: [Group:Number] : 0:0
> MaxProcessor: [Group:Number] : 0:2
> MaxProcessors : 2
> RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0
> IndirectionTable: [Group:Number] : 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
> 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2Das hat wohl geklappt. Wobei das scheinbar eh keine Auswirkung hatte. Zumindest keine Direkte, die man hätte spüren können.
Die Unterschied merkst du meistens dann, wenn du die Bandbreite der vNICs vollständig auslasten möchtest, das wird dir mit einer normalen Anwendung aber kaum gelingen. Ferner kann RSS bei einer falschen Konfiguration auch ausbremsen, aber das war bei dir, bei dieser VM ja gar nicht der Fall. Hier war das RSS lediglich ausgeschaltet, somit war die NIC zwar CPU technisch auf einen bestimmten Durchsatz limitiert, dieses Limit liegt aber meistens weit über 1G und ist somit für die meisten Clientanwendungen eh irrelevant, da kaum ein Client mit > 1G angebunden ist. Es gibt so ein Aberglauben, dass eine NIC ohne RSS nur 4G schaffen kann, aber das stimmt stand heute absolut nicht mehr. Habe dazu auch schon mal den folgenden Beitrag bei Spiceworks geschrieben.
https://community.spiceworks.com/topic/2269972-weird-4gbit-s-nic-limit-w ...
ODX habe ich noch nichts angepasst. Ist das schädlich wenn das läuft? Ich dachte damit findet ggfs. ein verschieben von Daten direkt auf dem Storage statt, statt erst über den Host zu gehen, oder nicht?
Wenn dein Storage selbst ODX nicht unterstützt, dann ist es im Sinne der Performance durchaus schädlich.
Zu diesem Thema werde ich in Kürze einen eigenständigen Artikel verfassen.
Bzgl. vmWare ging es mit da um die Server 2019 VMs, ob es da auch so Performance Probleme mit dem CUBIC gibt.
Ich kann dir diese Frage aus persönlicher Erfahrung nicht beantworten. Wir haben nur noch einen Kunden mit VMware im Bestand, dieser hat jodoch noch keine 2019er VM am laufen. Wenn ich jedoch dem Feedback von den Usern aus dem Schwesterpost bei Spiceworks vertrauen kann, dann definitiv ja.
Grüsse aus BaWü
Alex
Hallo Alex,
ich habe mir heute die diversen Threads in Spiceworks und hier durchgelesen und kann mich nur in die Schlange einreihen: Vielen vielen Dank für deinen Einsatz mit diesem Problem!
Auch mich erreichen immer mehr Störungsmeldungen, dass die Zugriffe auf den Fileserver langsam sind. Es ist dann immer das gleiche:
- Kopieren von Dateien von einem Win10 PC vom virtuellen Server 2019 Filer (OS und Files auf Raid5 SSD von HPE) ist sehr langsam
- Kopieren von einer Win10 VM (gleicher Hyper-V Host) vom virtuellen Filer 2019 ist sehr schnell
- Kopiere ich die Daten vom Filer auf den Hyper-V Host und hole Sie mir von dort vom physischen Win10 PC aus, ist es auch sehr schnell
-> Ergo liegt für mich das Problem irgendwo an der VM oder der Virtualisierung
Somit habe ich mir für mich deine Scripte/Befehle der diversen Threads zusammengefasst und würde dich bitten einmal zu schauen ob es so stimmt. Dies ist bestimmt auch für die anderen sehr hilfreich.
Auf dem Hyper-V Host sowie dem Filer/Guest:
Die letzte Zeile funktioniert natürlich nur auf dem Hyper-V Host.
Sollte dies nicht reichen, dann auf dem Win10 Client:
Damit sollte das Kopieren/Öffnen von Files dann auf jeden Fall schnell sein - dies hat sich heute in mehreren Tests auch so bestätigt.
Aber ist auch alles (noch) empfehlenswert so wie ich das mache?
Viele Grüße,
Johnny
ich habe mir heute die diversen Threads in Spiceworks und hier durchgelesen und kann mich nur in die Schlange einreihen: Vielen vielen Dank für deinen Einsatz mit diesem Problem!
Auch mich erreichen immer mehr Störungsmeldungen, dass die Zugriffe auf den Fileserver langsam sind. Es ist dann immer das gleiche:
- Kopieren von Dateien von einem Win10 PC vom virtuellen Server 2019 Filer (OS und Files auf Raid5 SSD von HPE) ist sehr langsam
- Kopieren von einer Win10 VM (gleicher Hyper-V Host) vom virtuellen Filer 2019 ist sehr schnell
- Kopiere ich die Daten vom Filer auf den Hyper-V Host und hole Sie mir von dort vom physischen Win10 PC aus, ist es auch sehr schnell
-> Ergo liegt für mich das Problem irgendwo an der VM oder der Virtualisierung
Somit habe ich mir für mich deine Scripte/Befehle der diversen Threads zusammengefasst und würde dich bitten einmal zu schauen ob es so stimmt. Dies ist bestimmt auch für die anderen sehr hilfreich.
Auf dem Hyper-V Host sowie dem Filer/Guest:
Set-NetTCPSetting -SettingName "InternetCustom" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "DatacenterCustom" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "Datacenter" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "Internet" -CongestionProvider DCTCP
netsh int tcp set global RSC=Disabled
Get-NetAdapter | Disable-NetAdapterRsc
Get-VMSwitch | Set-VMSwitch -EnableSoftwareRsc $falseSollte dies nicht reichen, dann auf dem Win10 Client:
1. Recv Segment Coalescing (IPv4) - set to Disabled (auf dem Netzwerkadapter)
2. Recv Segment Coalescing (IPv6) - set to Disabled (auf dem Netzwerkadapter)
3. Large Send Offload enabled - set to Disabled (auf dem Netzwerkadapter)
netsh int tcp set supplemental template=internet congestionprovider=DCTCP
netsh int tcp set supplemental template=internetcustom congestionprovider=DCTCP
netsh int tcp set supplemental template=Datacenter congestionprovider=DCTCP
netsh int tcp set supplemental template=Datacentercustom congestionprovider=DCTCPDamit sollte das Kopieren/Öffnen von Files dann auf jeden Fall schnell sein - dies hat sich heute in mehreren Tests auch so bestätigt.
Aber ist auch alles (noch) empfehlenswert so wie ich das mache?
Viele Grüße,
Johnny
Hi Johnny,
sorry für die Verspätung, habe deinen Post jetzt erst entdeckt.
Ich habe mich aus Zeitmangel entscheiden müssen, ob ich dieses Thema hier bei Administrator oder Spiceworks weiterverfolge und habe mich aufgrund von einer grösseren Reichweite fürs letztere entschieden. Soll jetzt aber nicht bedeuten, dass ich diesem Forum hier den Rücken gekehrt habe, ich kann mich momentan eben nicht um beides kümmern.
Nun zu deinen Fragen.
👍👍👍 da ist nichts verkehrtes dran.
Hast du die RSS Konfiguration mit Absicht ausgelassen?
Folgendes würde ich noch auf den 2019er VMs empfehlen, vor allem bei Fileservern, hilft aber auch bei Applikationsservern
wenn diese ebenfalls mit/über SMB arbeiten, aber auch bei Windows 10.
Ich habe die Tage den folgenden Uservoice bez. Hyper-V und Storageperformance erstellt und würde mich mich sehr über die eine oder andere Zustimmung/Stimme freuen.
https://windowsserver.uservoice.com/forums/295056-storage/suggestions/42 ...
Mehr Infos zu der write-through "Zwangskastration" gibt es unter anderem auch hier:
https://www.borncity.com/blog/2021/01/27/windows-server-2019-intel-rsc-u ...
https://community.spiceworks.com/topic/post/9032982
Grüsse aus BaWü
Alex
sorry für die Verspätung, habe deinen Post jetzt erst entdeckt.
Ich habe mich aus Zeitmangel entscheiden müssen, ob ich dieses Thema hier bei Administrator oder Spiceworks weiterverfolge und habe mich aufgrund von einer grösseren Reichweite fürs letztere entschieden. Soll jetzt aber nicht bedeuten, dass ich diesem Forum hier den Rücken gekehrt habe, ich kann mich momentan eben nicht um beides kümmern.
Nun zu deinen Fragen.
Auf dem Hyper-V Host sowie dem Filer/Guest:
Set-NetTCPSetting -SettingName "InternetCustom" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "DatacenterCustom" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "Datacenter" -CongestionProvider DCTCP
Set-NetTCPSetting -SettingName "Internet" -CongestionProvider DCTCP
netsh int tcp set global RSC=Disabled
Get-NetAdapter | Disable-NetAdapterRsc
Get-VMSwitch | Set-VMSwitch -EnableSoftwareRsc $false👍👍👍 da ist nichts verkehrtes dran.
Hast du die RSS Konfiguration mit Absicht ausgelassen?
Folgendes würde ich noch auf den 2019er VMs empfehlen, vor allem bei Fileservern, hilft aber auch bei Applikationsservern
wenn diese ebenfalls mit/über SMB arbeiten, aber auch bei Windows 10.
#SMB GENERAL TUNING
#NATIVE2019, HV2019, VM2019, NATIVEW10, VMW10
#Get-SmbServerConfiguration
#Get-SmbClientConfiguration
Set-SmbServerConfiguration -RequireSecuritySignature $false
Set-SmbClientConfiguration -EnableBandwidthThrottling $falseIch habe die Tage den folgenden Uservoice bez. Hyper-V und Storageperformance erstellt und würde mich mich sehr über die eine oder andere Zustimmung/Stimme freuen.
https://windowsserver.uservoice.com/forums/295056-storage/suggestions/42 ...
Mehr Infos zu der write-through "Zwangskastration" gibt es unter anderem auch hier:
https://www.borncity.com/blog/2021/01/27/windows-server-2019-intel-rsc-u ...
https://community.spiceworks.com/topic/post/9032982
Grüsse aus BaWü
Alex
Hi Alex, das hört sich sehr gut an.
Wir setzen seit einiger Zeit eine Nimble bei uns ein. Da kann ich mir das Thema Write-Through dann jetzt bestimmt auch noch vornehmen und die Performance noch weiter steigern oder?
Wir haben übrigens unser Problem mit der Applikation, die wir über SMB starten gefunden. Beide HyperV Host standen im BIOS auf dem Performance Profil "General Power Efficient Compute", was zur Folge hatte, das die CPU gar nicht richtig hochgetaktet hat.
Wir haben dann mal "Virtualization - Max Performance" eingestellt und schon flitzt die Kiste. 🙄
Interessant, dass auch die Server, die vom Systemhaus eingerichtet wurden, auf "General..." Standen.
Wir setzen seit einiger Zeit eine Nimble bei uns ein. Da kann ich mir das Thema Write-Through dann jetzt bestimmt auch noch vornehmen und die Performance noch weiter steigern oder?
Wir haben übrigens unser Problem mit der Applikation, die wir über SMB starten gefunden. Beide HyperV Host standen im BIOS auf dem Performance Profil "General Power Efficient Compute", was zur Folge hatte, das die CPU gar nicht richtig hochgetaktet hat.
Wir haben dann mal "Virtualization - Max Performance" eingestellt und schon flitzt die Kiste. 🙄
Interessant, dass auch die Server, die vom Systemhaus eingerichtet wurden, auf "General..." Standen.
1Zitat von @MysticFoxDE:
Moin Christian,
besteht die Möglichkeit, dass ich mir die Umgebung mal per Teamviewer anschauen kann?
Wenn ja, dann schicke ich dir meine Kontaktdaten per PN.
Grüsse aus BaWü
Alex
Moin Christian,
besteht die Möglichkeit, dass ich mir die Umgebung mal per Teamviewer anschauen kann?
Wenn ja, dann schicke ich dir meine Kontaktdaten per PN.
Grüsse aus BaWü
Alex
Hallo Alex,
seit 3 Tagen versuche ich das Performance Problem mit einer 10GB NIC und Hyper-V zu lösen, leider ohne Erfolg...
Ich habe den Thread per Google gefunden...
Auch wir setzen in unserem Ingenieurbüro 3 HP Server ein, einer hiervon ist ein Hyper-V Host und die anderen beiden "normale" Windows Server. Alle wurden nun mit einer 10GB von HPE (SFP+530) ausgestattet. Die Performance zwischen den "normalen" Servern ist super, nur zum Hype-V Server ist sie katastrophal, oft nicht mal 1GB... Bin seit 3 Tagen fast ununterbrochen auf der Fehlersuche, Firmware & Treiber geupdatet, alle möglichen Tipps im Internet ausprobiert, nichts bringt wirklich Abhilfe und langsam verzweifele ich.... Deshalb komme ich auf dich zu und wollte nachfragen ob es möglich wäre, dass du du dir das mal anschauen könntest? Vermute das es nix großes ist wahrscheinlich, aber mein Wissensstand von den Grundlagenthemen reicht wahrscheinlich nicht aus um strukturiert die Ursache zu suchen.
Zur Umgebung:
Server01: HP ProLiant DL380 Hyper-V Core 2019
Server02: HP ProLiant DL380 Windows Server 2016 Standard
Server03: HP ProLiant DL385 Windows Server 2019 Standard
Unifi 48 Port Pro Switch mit 4x SFP+
Performance zwischen Server02 und Server03 ist laut iperf super, nur mit Server01 nicht...
Würde mich über eine Rückmeldung freuen und mich natürlich erkenntlich zeigen bei Unterstützung
Vielen Dank & ein schönes Wochenende
Grüße Christian
Hey Christian,
hast du die Befehle alle einmal ausgeführt und neu gestartet? Alex bzw. Apoooo hatte die ja nochmal zusammengefasst.
Solltest du nur nicht im Produktivbetrieb machen, da einmal die Netzwerkverbindungen getrennt werden.
hast du die Befehle alle einmal ausgeführt und neu gestartet? Alex bzw. Apoooo hatte die ja nochmal zusammengefasst.
Solltest du nur nicht im Produktivbetrieb machen, da einmal die Netzwerkverbindungen getrennt werden.
Ja das habe ich bereits ausgeführt, leider ohne Erfolg...
Mir fehlt gerade bisschen der Ansatzpunkt wie ich auf die Ursachenforschung gehe...
Mir fehlt gerade bisschen der Ansatzpunkt wie ich auf die Ursachenforschung gehe...
Moin Christian,
ich benötige viel mehr Informationen um dir gezielter helfen zu können.
Wie sieht deine bisherige Netzwerkkonfiguration aus dem Hyper-V aus?
- wie viele NIC's
- wie sind diese Konfiguriert
- gibt es Teaming, wenn ja welches
Welche optimierungen hast du bereits vorgenommen?
Was spuckt z.B. "get-netadapterrss" und "get-netadapterrsc" aus?
Hast du die Energieeinstellungen im OS und auch im BIOS auf High-Performance gestellt?
Grüsse aus BaWü
Alex
ich benötige viel mehr Informationen um dir gezielter helfen zu können.
Wie sieht deine bisherige Netzwerkkonfiguration aus dem Hyper-V aus?
- wie viele NIC's
- wie sind diese Konfiguriert
- gibt es Teaming, wenn ja welches
Welche optimierungen hast du bereits vorgenommen?
Was spuckt z.B. "get-netadapterrss" und "get-netadapterrsc" aus?
Hast du die Energieeinstellungen im OS und auch im BIOS auf High-Performance gestellt?
Grüsse aus BaWü
Alex
Hallo Alex,
danke für deine Antwort.
Gerne gebe ich weitere Infos:
Bisher habe ich alle Möglichen Konfiguration probiert, die in diesem Thread und bei Spiceworks besprochen wurden. Auch habe ich geprüft ob die CPU Last oder ähnliches zu hoch ist, aber das scheint alles in Ordnung zu sein.
Zum Server der Probleme macht, er hat 2 NICs, eine mit 2x 10Gigabit und eine NIC mit 4x 1Gigabit. Angeschlossen ist nur einer der beiden 10Gigabit Ports, und ohne Teaming. Haben einen vSwitch erstellt und diesen den VMs zugewiesen. Dann eben deine Scripts ausgeführt und im Vorfeld alle Treiber und Firmware aktualisiert.
Zur Überbrückung habe ich nun die 4x 1Gigabit wieder reaktiviert und diese sind im Teaming, und einen 2. vSwitch erstellt.
Aber auch ohne diesen und wenn alle deaktiviert sind, sind die Probleme die gleichen.
Bei einem Test mit iperf kommen nur Raten von ca. 15-20 Mbit/s zustande, manchmal sogar nur um die 2 Mbit/s...
Die Ausgabe von "get-netadapterrss" und "get-netadapterrsc":
Es steht alles auf High Performance.
Vielen Dank vorab!
danke für deine Antwort.
Gerne gebe ich weitere Infos:
Bisher habe ich alle Möglichen Konfiguration probiert, die in diesem Thread und bei Spiceworks besprochen wurden. Auch habe ich geprüft ob die CPU Last oder ähnliches zu hoch ist, aber das scheint alles in Ordnung zu sein.
Zum Server der Probleme macht, er hat 2 NICs, eine mit 2x 10Gigabit und eine NIC mit 4x 1Gigabit. Angeschlossen ist nur einer der beiden 10Gigabit Ports, und ohne Teaming. Haben einen vSwitch erstellt und diesen den VMs zugewiesen. Dann eben deine Scripts ausgeführt und im Vorfeld alle Treiber und Firmware aktualisiert.
Zur Überbrückung habe ich nun die 4x 1Gigabit wieder reaktiviert und diese sind im Teaming, und einen 2. vSwitch erstellt.
Aber auch ohne diesen und wenn alle deaktiviert sind, sind die Probleme die gleichen.
Bei einem Test mit iperf kommen nur Raten von ca. 15-20 Mbit/s zustande, manchmal sogar nur um die 2 Mbit/s...
Die Ausgabe von "get-netadapterrss" und "get-netadapterrsc":
Name IPv4Enabled IPv6Enabled IPv4Operational IPv6Operational IPv4FailureReason IPv6FailureR
State State eason
---- ----------- ----------- --------------- --------------- ----------------- ------------
PCIe Slot 3 Port 1 False False False False NicPropertyDis... NicProper...
vEthernet (vSwitch) False False False False NicPropertyDis... NicProper...
PCIe Slot 3 Port 2 False False
4GBitLAN True True False False NetOffloadGlob... NetOffloa...Name : PCIe Slot 3 Port 1
InterfaceDescription : HPE Ethernet 10Gb 2-port 530SFP+ Adapter
Enabled : False
NumberOfReceiveQueues : 4
Profile : NUMAStatic
BaseProcessor: [Group:Number] : :0
MaxProcessor: [Group:Number] : :
MaxProcessors : 16
RssProcessorArray: [Group:Number/NUMA Distance] :
IndirectionTable: [Group:Number] :
Name : Embedded LOM 1 Port 1
InterfaceDescription : HPE Ethernet 1Gb 4-port 331i Adapter #3
Enabled : True
NumberOfReceiveQueues : 1
Profile : NUMAStatic
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:38
MaxProcessors : 16
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0
0:16/0 0:18/0 0:20/32767 0:22/32767 0:24/32767 0:26/32767
0:28/32767 0:30/32767
0:32/32767 0:34/32767 0:36/32767 0:38/32767
IndirectionTable: [Group:Number] :
Name : vEthernet (vSwitch)
InterfaceDescription : Hyper-V Virtual Ethernet Adapter
Enabled : False
NumberOfReceiveQueues : 8
Profile : ClosestStatic
BaseProcessor: [Group:Number] : :0
MaxProcessor: [Group:Number] : :63
MaxProcessors : 8
RssProcessorArray: [Group:Number/NUMA Distance] :
IndirectionTable: [Group:Number] :
Name : PCIe Slot 3 Port 2
InterfaceDescription : HPE Ethernet 10Gb 2-port 530SFP+ Adapter #2
Enabled : True
NumberOfReceiveQueues : 4
Profile : NUMAStatic
BaseProcessor: [Group:Number] : :0
MaxProcessor: [Group:Number] : :
MaxProcessors : 16
RssProcessorArray: [Group:Number/NUMA Distance] :
IndirectionTable: [Group:Number] :
Name : 4GBitLAN
InterfaceDescription : Microsoft Network Adapter Multiplexor Driver
Enabled : True
NumberOfReceiveQueues : 0
Profile : NUMAStatic
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:38
MaxProcessors : 4
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0
0:16/0 0:18/0 0:20/0 0:22/0 0:24/0 0:26/0 0:28/0 0:30/0
0:32/0 0:34/0 0:36/0 0:38/0
IndirectionTable: [Group:Number] :
Name : Embedded LOM 1 Port 4
InterfaceDescription : HPE Ethernet 1Gb 4-port 331i Adapter #4
Enabled : True
NumberOfReceiveQueues : 1
Profile : NUMAStatic
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:38
MaxProcessors : 16
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0
0:16/0 0:18/0 0:20/32767 0:22/32767 0:24/32767 0:26/32767
0:28/32767 0:30/32767
0:32/32767 0:34/32767 0:36/32767 0:38/32767
IndirectionTable: [Group:Number] :
Name : Embedded LOM 1 Port 2
InterfaceDescription : HPE Ethernet 1Gb 4-port 331i Adapter
Enabled : True
NumberOfReceiveQueues : 1
Profile : NUMAStatic
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:38
MaxProcessors : 16
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0
0:16/0 0:18/0 0:20/32767 0:22/32767 0:24/32767 0:26/32767
0:28/32767 0:30/32767
0:32/32767 0:34/32767 0:36/32767 0:38/32767
IndirectionTable: [Group:Number] :
Name : Embedded LOM 1 Port 3
InterfaceDescription : HPE Ethernet 1Gb 4-port 331i Adapter #2
Enabled : True
NumberOfReceiveQueues : 1
Profile : NUMAStatic
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:38
MaxProcessors : 16
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0
0:16/0 0:18/0 0:20/32767 0:22/32767 0:24/32767 0:26/32767
0:28/32767 0:30/32767
0:32/32767 0:34/32767 0:36/32767 0:38/32767
IndirectionTable: [Group:Number] :Es steht alles auf High Performance.
Vielen Dank vorab!
Moin Christian,
bevor wir uns an das Netzwerk ranmachen, möchte ich pauschal das folgende los werden.
Unter bestimmten Bedingungen läuft ein Physikalischer Server, ohne Installierte Hyper-V Rolle, viel schneller als mit. Dies betrifft insbesondere Szenarien, bei denen sehr viele Daten geschrieben werden. Der Hintergrund dafür ist folgend. Sobald auf einem Server die Hyper-V Rolle installiert ist, werden alle Schreiboperationen von dem Hyper-V Storagestack richtung das dahinterliegende Storagesubsystem (RAID, SAN oder auch einzelne SSD) mit einem „Write-Through“ Flag weitergegeben. Und das sorgt am ende des Tages dafür, das der vor allem in den SAN’s, sau teure Cache, beim Schreiben vollkommen übergangen wird. 🤮
Nur die Ethernus Storages von Fujitsu scheinen hier wiederum ein eigenes Süppchen zu kochen, wenn man bei einem Ethernus SAN in der Controllerpolicy „Write-Back“ einstellt, dann jagt die Ethernus alles über den Cache durch, unabhängig davon, ob der schreib-IO vom OS/Applikation als „Write-Through“ gekennzeichnet ist oder nicht, was so eigentlich auch nicht ganz korrekt ist. 🙃
---
Nun zu deiner Netzwerkkonfiguration.
Ich sehe auf Anhieb mehrere Probleme.
Du verwendest für das Teaming LBFO, von dieser Teamingvariante rät Microsoft bei einem 2019er Server aktiv ab. An dieser Stelle solltest du daher auf SET umstellen.
Das geht sehr einfach mit den folgenden Befehlen, dazu musst du aber vorher den bisherigen vSwitch löschen und auch das LBFO Teaming vorher auflösen.
Bitte auf dem dahinterliegenden Switch KEIN Teaming für diese vier Ports konfigurieren!!!
Und bitte auch nicht gleich hergehen und als erstes den vSwich mit dem SET erstellen.
Dieser Schritt sollte erst gemacht werden, wen die für das SET verwendeten NIC’s bereits schon optimiert sind.
🤔, das spricht dafür, dass das Storage bei diesem Problem nicht das ausschlaggebende ist.
Deine NICs sind so wie ich das sehe, weder NUMA noch Core optimiert, wahrscheinlich ist bereits das auch schon das Problem.
Ich möchte als nächstes Schritt für Schritt die jetzige RSS Konfiguration einer der 1G NIC’s durchgehen und anmerken, was mir bei dieser sauer aufstosst.
NumberOfReceiveQueues : 1
MaxProcessors : 16
😮 OK, eigentlich sollte das Verhältnis von Queues zu MaxProcessors bei einem normal belasteten System 1:1 sein und bei einem extrem belasteten bei 1:2, aber 1:16 😧😬 das ist absoluter Humbug.
Dazu folgendes Beispiel:
In dem oberen Screenshot die RSS Konfiguration meiner 10G Workstation NIC zu sehen.
In diesem Beispiel sind der NIC 8 Queues und 8 CPUs zugeordnet und in der IndirectionTabe sieht man auch genau, das die 8 Queues sauber auf die 8 Kerne aufgeteilt werden.
Wenn ich nun hergehe und nur die RSS-Queue auf 4 herabsenke und die RSS-MaxProzessors auf 8 belasse, dann kommt das folgende dabei heraus.
RSS stehen bei dieser Konfiguration nur noch 4 Kerne aktiv zur Verfügung.
Jetzt noch das Spielchen mit zwei Kernen.
Und jetzt kommt das Entscheidendste.
Mit nur einer Queue ist bei meiner NIC RSS absolut nicht funktionsfähig, weil RSS mit nur einer Queue absolut keinen Sinn macht!
Hast du die RSS-Queues auf diesen NIC’s selbst angepasst?
Oder hat hier HP bei den Treibern ordentlich Mist gebaut?
Ich persönlich tippe aus Erfahrung eher auf das Letztere.
Nun ja, dieser Murks sollte sich mit dem folgenden Befehl auf deinen 1G NIC’s leicht beheben lassen.
Als nächstes noch die MaxProcessors mit dem folgenden Befehl passen korrigieren und schon passt es zumindest was diese beiden Einstellungen angeht.
Auf die nächsten Punkte komme ich später zurück, meine beiden Hausdrachen sind wach, jetzt muss ich mich etwas um diese kümmern. 😜
Beste Grüsse aus BaWü
Alex
bevor wir uns an das Netzwerk ranmachen, möchte ich pauschal das folgende los werden.
Unter bestimmten Bedingungen läuft ein Physikalischer Server, ohne Installierte Hyper-V Rolle, viel schneller als mit. Dies betrifft insbesondere Szenarien, bei denen sehr viele Daten geschrieben werden. Der Hintergrund dafür ist folgend. Sobald auf einem Server die Hyper-V Rolle installiert ist, werden alle Schreiboperationen von dem Hyper-V Storagestack richtung das dahinterliegende Storagesubsystem (RAID, SAN oder auch einzelne SSD) mit einem „Write-Through“ Flag weitergegeben. Und das sorgt am ende des Tages dafür, das der vor allem in den SAN’s, sau teure Cache, beim Schreiben vollkommen übergangen wird. 🤮
Nur die Ethernus Storages von Fujitsu scheinen hier wiederum ein eigenes Süppchen zu kochen, wenn man bei einem Ethernus SAN in der Controllerpolicy „Write-Back“ einstellt, dann jagt die Ethernus alles über den Cache durch, unabhängig davon, ob der schreib-IO vom OS/Applikation als „Write-Through“ gekennzeichnet ist oder nicht, was so eigentlich auch nicht ganz korrekt ist. 🙃
---
Nun zu deiner Netzwerkkonfiguration.
Ich sehe auf Anhieb mehrere Probleme.
Zur Überbrückung habe ich nun die 4x 1Gigabit wieder reaktiviert und diese sind im Teaming, und einen 2. vSwitch erstellt.
Du verwendest für das Teaming LBFO, von dieser Teamingvariante rät Microsoft bei einem 2019er Server aktiv ab. An dieser Stelle solltest du daher auf SET umstellen.
Das geht sehr einfach mit den folgenden Befehlen, dazu musst du aber vorher den bisherigen vSwitch löschen und auch das LBFO Teaming vorher auflösen.
New-VMSwitch -Name "VSWITCHNAME" -NetAdapterName "NIC1.1-N1GAI-MAIN", "NIC2.1-N1GAI-MAIN" -EnableEmbeddedTeaming $true -AllowManagementOS $false -EnableIov $false -EnablePacketDirect $false
Set-VMSwitchTeam -Name " VSWITCHNAME " -LoadBalancingAlgorithm Dynamic -TeamingMode SwitchIndependent
Set-VMSwitch -Name " VSWITCHNAME" -EnableSoftwareRsc $false Bitte auf dem dahinterliegenden Switch KEIN Teaming für diese vier Ports konfigurieren!!!
Und bitte auch nicht gleich hergehen und als erstes den vSwich mit dem SET erstellen.
Dieser Schritt sollte erst gemacht werden, wen die für das SET verwendeten NIC’s bereits schon optimiert sind.
Bei einem Test mit iperf kommen nur Raten von ca. 15-20 Mbit/s zustande, manchmal sogar nur um die 2 Mbit/s...
🤔, das spricht dafür, dass das Storage bei diesem Problem nicht das ausschlaggebende ist.
Deine NICs sind so wie ich das sehe, weder NUMA noch Core optimiert, wahrscheinlich ist bereits das auch schon das Problem.
Ich möchte als nächstes Schritt für Schritt die jetzige RSS Konfiguration einer der 1G NIC’s durchgehen und anmerken, was mir bei dieser sauer aufstosst.
Name : Embedded LOM 1 Port 1
InterfaceDescription : HPE Ethernet 1Gb 4-port 331i Adapter #3
Enabled : True
NumberOfReceiveQueues : 1
Profile : NUMAStatic
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:38
MaxProcessors : 16
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 >0:12/0 0:14/0
0:16/0 0:18/0 0:20/32767 0:22/32767 0:24/32767 0:26/32767
0:28/32767 0:30/32767
0:32/32767 0:34/32767 0:36/32767 0:38/32767
IndirectionTable: [Group:Number] : NumberOfReceiveQueues : 1
MaxProcessors : 16
😮 OK, eigentlich sollte das Verhältnis von Queues zu MaxProcessors bei einem normal belasteten System 1:1 sein und bei einem extrem belasteten bei 1:2, aber 1:16 😧😬 das ist absoluter Humbug.
Dazu folgendes Beispiel:
In dem oberen Screenshot die RSS Konfiguration meiner 10G Workstation NIC zu sehen.
In diesem Beispiel sind der NIC 8 Queues und 8 CPUs zugeordnet und in der IndirectionTabe sieht man auch genau, das die 8 Queues sauber auf die 8 Kerne aufgeteilt werden.
Wenn ich nun hergehe und nur die RSS-Queue auf 4 herabsenke und die RSS-MaxProzessors auf 8 belasse, dann kommt das folgende dabei heraus.
RSS stehen bei dieser Konfiguration nur noch 4 Kerne aktiv zur Verfügung.
Jetzt noch das Spielchen mit zwei Kernen.
Und jetzt kommt das Entscheidendste.
Mit nur einer Queue ist bei meiner NIC RSS absolut nicht funktionsfähig, weil RSS mit nur einer Queue absolut keinen Sinn macht!
Hast du die RSS-Queues auf diesen NIC’s selbst angepasst?
Oder hat hier HP bei den Treibern ordentlich Mist gebaut?
Ich persönlich tippe aus Erfahrung eher auf das Letztere.
Nun ja, dieser Murks sollte sich mit dem folgenden Befehl auf deinen 1G NIC’s leicht beheben lassen.
Get-NetAdapterRss -Name "Embedded LOM 1 Port 1", "Embedded LOM 1 Port 2", "Embedded LOM 1 Port 3", "Embedded LOM 1 Port 4" | Set-NetAdapterRss -NumberOfReceiveQueues 2 Als nächstes noch die MaxProcessors mit dem folgenden Befehl passen korrigieren und schon passt es zumindest was diese beiden Einstellungen angeht.
Get-NetAdapterRss -Name "Embedded LOM 1 Port 1", "Embedded LOM 1 Port 2", "Embedded LOM 1 Port 3", "Embedded LOM 1 Port 4" | Set-NetAdapterRss – MaxProcessors 2 Auf die nächsten Punkte komme ich später zurück, meine beiden Hausdrachen sind wach, jetzt muss ich mich etwas um diese kümmern. 😜
Beste Grüsse aus BaWü
Alex
Vielen Dank schonmal
Um Missverständnisse zu vermeiden, bei dem vSwitch mit 4x 1Gigabit sind die Datenraten bei um die 500-600 Mbit/s. Die massiv schlechten Raten von 2 Mbit/s kommt nur wenn ich die 10 Gigabit NIC nutze ohne Teaming...
Hatte auch auf Anraten verschiedener "Google Ergebnisse" Jumbo Frames mal aktiviert. Wie ist deine Meinung dazu?
Das ergibt der Speedtest mit der 10Gbit NIC auf dem Hyper-V Host:
Paar Minuten davor war das Ergebnis ein "wenig" besser:
Und nach der Optimierung der 4x 1Gbit NIC ergibt der Speedtest in einer VM folgendes:
Um Missverständnisse zu vermeiden, bei dem vSwitch mit 4x 1Gigabit sind die Datenraten bei um die 500-600 Mbit/s. Die massiv schlechten Raten von 2 Mbit/s kommt nur wenn ich die 10 Gigabit NIC nutze ohne Teaming...
Hatte auch auf Anraten verschiedener "Google Ergebnisse" Jumbo Frames mal aktiviert. Wie ist deine Meinung dazu?
Das ergibt der Speedtest mit der 10Gbit NIC auf dem Hyper-V Host:
C:\tmp\iperf>iperf3.exe -c 10.0.0.33
Connecting to host 10.0.0.33, port 5201
[ 4] local 10.0.0.22 port 60659 connected to 10.0.0.33 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.02 sec 640 KBytes 5.16 Mbits/sec
[ 4] 1.02-2.00 sec 128 KBytes 1.07 Mbits/sec
[ 4] 2.00-3.02 sec 256 KBytes 2.06 Mbits/sec
[ 4] 3.02-4.02 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.02-5.02 sec 512 KBytes 4.19 Mbits/sec
[ 4] 5.02-6.02 sec 128 KBytes 1.05 Mbits/sec
[ 4] 6.02-7.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 7.00-8.02 sec 256 KBytes 2.06 Mbits/sec
[ 4] 8.02-9.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 9.00-10.00 sec 256 KBytes 2.10 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 2.12 MBytes 1.78 Mbits/sec sender
[ 4] 0.00-10.00 sec 1.93 MBytes 1.62 Mbits/sec receiver
iperf Done.Paar Minuten davor war das Ergebnis ein "wenig" besser:
C:\tmp\iperf>iperf3.exe -c 10.0.0.33
Connecting to host 10.0.0.33, port 5201
[ 4] local 10.0.0.22 port 60650 connected to 10.0.0.33 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.02 sec 1.62 MBytes 13.4 Mbits/sec
[ 4] 1.02-2.02 sec 2.25 MBytes 18.9 Mbits/sec
[ 4] 2.02-3.02 sec 4.50 MBytes 37.7 Mbits/sec
[ 4] 3.02-4.02 sec 2.38 MBytes 19.9 Mbits/sec
[ 4] 4.02-5.02 sec 640 KBytes 5.24 Mbits/sec
[ 4] 5.02-6.02 sec 2.75 MBytes 23.1 Mbits/sec
[ 4] 6.02-7.00 sec 1.50 MBytes 12.8 Mbits/sec
[ 4] 7.00-8.02 sec 2.88 MBytes 23.8 Mbits/sec
[ 4] 8.02-9.02 sec 2.38 MBytes 19.9 Mbits/sec
[ 4] 9.02-10.02 sec 2.25 MBytes 18.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.02 sec 23.1 MBytes 19.4 Mbits/sec sender
[ 4] 0.00-10.02 sec 23.0 MBytes 19.3 Mbits/sec receiver
iperf Done.Und nach der Optimierung der 4x 1Gbit NIC ergibt der Speedtest in einer VM folgendes:
Connecting to host 10.0.0.33, port 5201
[ 4] local 10.0.0.3 port 56913 connected to 10.0.0.33 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 85.2 MBytes 715 Mbits/sec
[ 4] 1.00-2.00 sec 103 MBytes 863 Mbits/sec
[ 4] 2.00-3.00 sec 101 MBytes 848 Mbits/sec
[ 4] 3.00-4.00 sec 86.1 MBytes 722 Mbits/sec
[ 4] 4.00-5.00 sec 89.6 MBytes 752 Mbits/sec
[ 4] 5.00-6.00 sec 92.8 MBytes 778 Mbits/sec
[ 4] 6.00-7.00 sec 104 MBytes 869 Mbits/sec
[ 4] 7.00-8.00 sec 104 MBytes 874 Mbits/sec
[ 4] 8.00-9.00 sec 102 MBytes 857 Mbits/sec
[ 4] 9.00-10.00 sec 103 MBytes 861 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 970 MBytes 814 Mbits/sec sender
[ 4] 0.00-10.00 sec 970 MBytes 814 Mbits/sec receiver
iperf Done.
Moin Christian,
kannst du mir bitte kurz die Ausgabe von "Get-NetAdapterHardwareInfo" posten, danke.
Gruss Alex
kannst du mir bitte kurz die Ausgabe von "Get-NetAdapterHardwareInfo" posten, danke.
Gruss Alex
Moin Christian,
Wenn ich das jetzt richtig verstanden habe, dann hat die Optimierung der beiden Parameter bei den 1G NIC's bereits Früchte getragen.
Ist das korrekt so?
Gruss Alex
bei dem vSwitch mit 4x 1Gigabit sind die Datenraten bei um die 500-600 Mbit/s.
Und nach der Optimierung der 4x 1Gbit NIC ergibt der Speedtest in einer VM folgendes:
Connecting to host 10.0.0.33, port 5201
> [ 4] local 10.0.0.3 port 56913 connected to 10.0.0.33 port 5201
> [ ID] Interval Transfer Bandwidth
> [ 4] 0.00-1.00 sec 85.2 MBytes 715 Mbits/sec
> [ 4] 1.00-2.00 sec 103 MBytes 863 Mbits/sec
> [ 4] 2.00-3.00 sec 101 MBytes 848 Mbits/sec
> [ 4] 3.00-4.00 sec 86.1 MBytes 722 Mbits/sec
> [ 4] 4.00-5.00 sec 89.6 MBytes 752 Mbits/sec
> [ 4] 5.00-6.00 sec 92.8 MBytes 778 Mbits/sec
> [ 4] 6.00-7.00 sec 104 MBytes 869 Mbits/sec
> [ 4] 7.00-8.00 sec 104 MBytes 874 Mbits/sec
> [ 4] 8.00-9.00 sec 102 MBytes 857 Mbits/sec
> [ 4] 9.00-10.00 sec 103 MBytes 861 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bandwidth
> [ 4] 0.00-10.00 sec 970 MBytes 814 Mbits/sec sender
> [ 4] 0.00-10.00 sec 970 MBytes 814 Mbits/sec receiver
>
> iperf Done.Wenn ich das jetzt richtig verstanden habe, dann hat die Optimierung der beiden Parameter bei den 1G NIC's bereits Früchte getragen.
Ist das korrekt so?
Gruss Alex
Zitat von @MysticFoxDE:
Moin Christian,
kannst du mir bitte kurz die Ausgabe von "Get-NetAdapterHardwareInfo" posten, danke.
Gruss Alex
Moin Christian,
kannst du mir bitte kurz die Ausgabe von "Get-NetAdapterHardwareInfo" posten, danke.
Gruss Alex
Na klar
Name Segment Bus Device Function Slot NumaNode PcieLinkSpeed PcieLinkWidth Version
---- ------- --- ------ -------- ---- -------- ------------- ------------- -------
PCIe Slot 3 Port 1 0 19 0 0 3 0 5.0 GT/s 8 1.1
Embedded LOM 1 Port 1 0 2 0 0 0 5.0 GT/s 2 1.1
PCIe Slot 3 Port 2 0 19 0 1 3 0 5.0 GT/s 8 1.1
Embedded LOM 1 Port 4 0 2 0 3 0 5.0 GT/s 2 1.1
Embedded LOM 1 Port 2 0 2 0 1 0 5.0 GT/s 2 1.1
Embedded LOM 1 Port 3 0 2 0 2 0 5.0 GT/s 2 1.1Zitat von @MysticFoxDE:
Moin Christian,
Wenn ich das jetzt richtig verstanden habe, dann hat die Optimierung der beiden Parameter bei den 1G NIC's bereits Früchte getragen.
Ist das korrekt so?
Gruss Alex
Moin Christian,
bei dem vSwitch mit 4x 1Gigabit sind die Datenraten bei um die 500-600 Mbit/s.
Und nach der Optimierung der 4x 1Gbit NIC ergibt der Speedtest in einer VM folgendes:
Connecting to host 10.0.0.33, port 5201
>> [ 4] local 10.0.0.3 port 56913 connected to 10.0.0.33 port 5201
>> [ ID] Interval Transfer Bandwidth
>> [ 4] 0.00-1.00 sec 85.2 MBytes 715 Mbits/sec
>> [ 4] 1.00-2.00 sec 103 MBytes 863 Mbits/sec
>> [ 4] 2.00-3.00 sec 101 MBytes 848 Mbits/sec
>> [ 4] 3.00-4.00 sec 86.1 MBytes 722 Mbits/sec
>> [ 4] 4.00-5.00 sec 89.6 MBytes 752 Mbits/sec
>> [ 4] 5.00-6.00 sec 92.8 MBytes 778 Mbits/sec
>> [ 4] 6.00-7.00 sec 104 MBytes 869 Mbits/sec
>> [ 4] 7.00-8.00 sec 104 MBytes 874 Mbits/sec
>> [ 4] 8.00-9.00 sec 102 MBytes 857 Mbits/sec
>> [ 4] 9.00-10.00 sec 103 MBytes 861 Mbits/sec
>> - - - - - - - - - - - - - - - - - - - - - - - - -
>> [ ID] Interval Transfer Bandwidth
>> [ 4] 0.00-10.00 sec 970 MBytes 814 Mbits/sec sender
>> [ 4] 0.00-10.00 sec 970 MBytes 814 Mbits/sec receiver
>>
>> iperf Done.Wenn ich das jetzt richtig verstanden habe, dann hat die Optimierung der beiden Parameter bei den 1G NIC's bereits Früchte getragen.
Ist das korrekt so?
Gruss Alex
Ja die Datenraten sind schon etwas besser geworden ja
Jedoch sollten sie aufgrund des Teamings eigtl höher sein, aber es geht auch primär um die 10 Gbit NIC, die die 1 Gbit NICs ablösen soll...
😮 OK > 23.000 Mal gelesen, das Problem scheinen wohl doch zwei drei Admins mehr zu haben. 😔
1
Moin Zusammen,
der folgende Beitrag hat übriges direkt etwas mit dem Thema aus diesem Beitrag zu tun. 😉
RAM-Zugriff auf einem neuen High-Performance Server, teilweise um Welten langsamer als auf einer Workstation
Kleine Gedankenanschupshilfe:
Wo liegen die Sende.- und Empfangspuffer der Netzwerkkarten?
Beste Grüsse aus BaWü
Alex
P.S.
Happy Sysadminday!
der folgende Beitrag hat übriges direkt etwas mit dem Thema aus diesem Beitrag zu tun. 😉
RAM-Zugriff auf einem neuen High-Performance Server, teilweise um Welten langsamer als auf einer Workstation
Kleine Gedankenanschupshilfe:
Wo liegen die Sende.- und Empfangspuffer der Netzwerkkarten?
Beste Grüsse aus BaWü
Alex
P.S.
Happy Sysadminday!
was ich noch rausgefunden habe - windows selber kann anscheinend nie schneller als mit 1.6GB/s kopieren, weil die explorer.exe da der limitierende faktor ist. nur das tool FastCopy kann die maximale bandbreite nutzen...
ist mir aufgefallen als ich von einer vNME SSD auf eine andere was kopiren wollte, wo beide eigentlich über 4GB/s lesen und schreiben können.
Das nächste was mir aufgefallen ist, wenn man neben dem HyperV noch einen Failovercluster drauf setzt, dieses ClusterSharedVolume ist auch brechend lahm bei uns....innerhalb einer VM die auf dem Cluster liegt kann ich nur mit rund 250MB/s dateien kopieren auf sich selbst
Auch von einer VM in eine andere VM die auf dem selben ClusterKnoten liegt - kann ich nur mit 250MB/s kopieren. Egal ob ich meine 10G karten über ein SET oder LBFO geteamt habe oder nur eine einzelne karte klassisch an dem vSwitch angebunden habe.
die performance kotzt mich maßlos an beim Server 2019...da zahlt man etliche Zehntausende Euro für zwei sehr starke Server die im Cluster laufen sollen, und dan krebsen die bei 200-300MB/s rum. Das hatte man im Jahre 2005 diese Leistung
Auch Benchmarkprogramme wie ATTO oder CrystalDiskBench - die liefern alle irgendwelche unmöglich hohen benchmark-scores auf nem 2019er HyperV Host - der technisch garnicht möglich ist...da wird mir 4GB/s sequentiuell schreibend gesagt bei nem RAID6 - obwohl der controller nur mit PCI 2.0 4x angebunden ist bei dem test...beim reinen Datei Kopieren auf dem Host kommen da nur noch rund 100MB/s zusammen...verstehe ich nicht sowas
Früher hatte man bei weitem nicht so einen stress/aufwand betreiben müssen, da hatte man sich nen neuen Server gekauft, hingestellt, windows 2008R2 drauf und gestaunt wie schnell das alles lief...und heute wird jeder server gefühl immer langsamer xD
ist mir aufgefallen als ich von einer vNME SSD auf eine andere was kopiren wollte, wo beide eigentlich über 4GB/s lesen und schreiben können.
Das nächste was mir aufgefallen ist, wenn man neben dem HyperV noch einen Failovercluster drauf setzt, dieses ClusterSharedVolume ist auch brechend lahm bei uns....innerhalb einer VM die auf dem Cluster liegt kann ich nur mit rund 250MB/s dateien kopieren auf sich selbst
Auch von einer VM in eine andere VM die auf dem selben ClusterKnoten liegt - kann ich nur mit 250MB/s kopieren. Egal ob ich meine 10G karten über ein SET oder LBFO geteamt habe oder nur eine einzelne karte klassisch an dem vSwitch angebunden habe.
die performance kotzt mich maßlos an beim Server 2019...da zahlt man etliche Zehntausende Euro für zwei sehr starke Server die im Cluster laufen sollen, und dan krebsen die bei 200-300MB/s rum. Das hatte man im Jahre 2005 diese Leistung
Auch Benchmarkprogramme wie ATTO oder CrystalDiskBench - die liefern alle irgendwelche unmöglich hohen benchmark-scores auf nem 2019er HyperV Host - der technisch garnicht möglich ist...da wird mir 4GB/s sequentiuell schreibend gesagt bei nem RAID6 - obwohl der controller nur mit PCI 2.0 4x angebunden ist bei dem test...beim reinen Datei Kopieren auf dem Host kommen da nur noch rund 100MB/s zusammen...verstehe ich nicht sowas
Früher hatte man bei weitem nicht so einen stress/aufwand betreiben müssen, da hatte man sich nen neuen Server gekauft, hingestellt, windows 2008R2 drauf und gestaunt wie schnell das alles lief...und heute wird jeder server gefühl immer langsamer xD
Moin Assassin,
Das der Explorer langsamer ist wie FastCopy, hat nicht mit einem Limit zu tun sondern eher mit einer unterschiedlichen Arbeitsweise. Der Explorer schiebt die Daten per Singlethread von A nach B und FastCopy arbeitet mit Multithreading.
https://fastcopy.jp/
"Because it uses multi-threads for Read/Write/Verify, Overlapped I/O, Direct I/O, so it brings out the best speed of devices."
Das hat wahrscheinlich etwas mit dem von Microsoft erzwungenen Write-Through zu tun, wodurch das Write-Caching von so gut wie jedem SAN und RAID-Controller ausgehebelt wird. 🤮
Wenn die VM's auf demselben Clusterknoten laufen und auch mit demselben vSwitch verbunden sind und es ist kein SR-IOV aktiviert, dann spielen die Uplinks des vSwitches bei der Transferperformance zwischen diesen VM's, absolut keine Rolle.
Sprich, dieses Problem wird wahrscheinlich nicht durch das SDN verursacht.
Habe gerade für ~60K drei nigelnagelneue Hochleistungsmonster hinter meinem Rücken stehen die auch nicht so ganz wollen wie ich gerne hätte. Ich habe mich mit diesen die letzten Wochen sehr intensiv beschäftigt und bin glaube ich auf einem guten Weg, den 2019 doch wieder flott zu bekommen. 😁
Bei vielen Dingen die mir jüngst aufgefallen sind, muss ich Microsoft jedoch eher in Schutz nehmen.
Die Hardwarehersteller sind bei diesem Thema nämlich auch alles andere als unschuldig.
Beste Grüsse aus BaWü
Alex
was ich noch rausgefunden habe - windows selber kann anscheinend nie schneller als mit 1.6GB/s kopieren, weil die explorer.exe da der limitierende faktor ist. nur das tool FastCopy kann die maximale bandbreite nutzen...
ist mir aufgefallen als ich von einer vNME SSD auf eine andere was kopiren wollte, wo beide eigentlich über 4GB/s lesen und schreiben können.
ist mir aufgefallen als ich von einer vNME SSD auf eine andere was kopiren wollte, wo beide eigentlich über 4GB/s lesen und schreiben können.
Das der Explorer langsamer ist wie FastCopy, hat nicht mit einem Limit zu tun sondern eher mit einer unterschiedlichen Arbeitsweise. Der Explorer schiebt die Daten per Singlethread von A nach B und FastCopy arbeitet mit Multithreading.
https://fastcopy.jp/
"Because it uses multi-threads for Read/Write/Verify, Overlapped I/O, Direct I/O, so it brings out the best speed of devices."
Das nächste was mir aufgefallen ist, wenn man neben dem HyperV noch einen Failovercluster drauf setzt, dieses ClusterSharedVolume ist auch brechend lahm bei uns....innerhalb einer VM die auf dem Cluster liegt kann ich nur mit rund 250MB/s dateien kopieren auf sich selbst
Das hat wahrscheinlich etwas mit dem von Microsoft erzwungenen Write-Through zu tun, wodurch das Write-Caching von so gut wie jedem SAN und RAID-Controller ausgehebelt wird. 🤮
Auch von einer VM in eine andere VM die auf dem selben ClusterKnoten liegt - kann ich nur mit 250MB/s kopieren. Egal ob ich meine 10G karten über ein SET oder LBFO geteamt habe oder nur eine einzelne karte klassisch an dem vSwitch angebunden habe.
Wenn die VM's auf demselben Clusterknoten laufen und auch mit demselben vSwitch verbunden sind und es ist kein SR-IOV aktiviert, dann spielen die Uplinks des vSwitches bei der Transferperformance zwischen diesen VM's, absolut keine Rolle.
Sprich, dieses Problem wird wahrscheinlich nicht durch das SDN verursacht.
die performance kotzt mich maßlos an beim Server 2019...da zahlt man etliche Zehntausende Euro für zwei sehr starke Server die im Cluster laufen sollen, und dan krebsen die bei 200-300MB/s rum. Das hatte man im Jahre 2005 diese Leistung
Habe gerade für ~60K drei nigelnagelneue Hochleistungsmonster hinter meinem Rücken stehen die auch nicht so ganz wollen wie ich gerne hätte. Ich habe mich mit diesen die letzten Wochen sehr intensiv beschäftigt und bin glaube ich auf einem guten Weg, den 2019 doch wieder flott zu bekommen. 😁
Bei vielen Dingen die mir jüngst aufgefallen sind, muss ich Microsoft jedoch eher in Schutz nehmen.
Die Hardwarehersteller sind bei diesem Thema nämlich auch alles andere als unschuldig.
Beste Grüsse aus BaWü
Alex
Intel hat immerhin RSC aus den neueren Treibern rausgenommen :D
aber nirgendwo steht ob man bei einer 10G Netzwerkkarte flusskontrolle anhaben sollte oder nicht, was ist mit der Interrupt-Drosselung, oder LSO oder der ganze andere Offload-mist...
die vielen einstellmöglichkeiten sind ja nicht ohne grund da, aber da jetzt wochen und Monate an zeit verplembern um das selber rauszufinden was welche einstellung macht?
aber nirgendwo steht ob man bei einer 10G Netzwerkkarte flusskontrolle anhaben sollte oder nicht, was ist mit der Interrupt-Drosselung, oder LSO oder der ganze andere Offload-mist...
die vielen einstellmöglichkeiten sind ja nicht ohne grund da, aber da jetzt wochen und Monate an zeit verplembern um das selber rauszufinden was welche einstellung macht?
Moin Assassin,
Wenn dir Performance lieb ist, dann solltest du LSO und RSC (unnütze Latenzerzeuger) niemals und nirgends verwenden, gilt auch weitestgehend für die Interrupt-Drosselung (altes Relikt + Latenzerzeuger).
Mit der Flusskontrolle solltest du auch sehr vorsichtig umgehen, diese erzeugt mit zwei weiteren TCP-Stack Features die du nicht so einfach per GUI oder PowerShell abschalten kannst, in manchen Situationen für ~3 Minuten einen TCP Deadlock. 🤢
Beste Grüsse aus BaWü
Alex
Intel hat immerhin RSC aus den neueren Treibern rausgenommen :D
Ich weiss, bin glaube ich nicht ganz unschuldig daran. 😎aber nirgendwo steht ob man bei einer 10G Netzwerkkarte flusskontrolle anhaben sollte oder nicht, was ist mit der Interrupt-Drosselung, oder LSO oder der ganze andere Offload-mist...
Wenn dir Performance lieb ist, dann solltest du LSO und RSC (unnütze Latenzerzeuger) niemals und nirgends verwenden, gilt auch weitestgehend für die Interrupt-Drosselung (altes Relikt + Latenzerzeuger).
Mit der Flusskontrolle solltest du auch sehr vorsichtig umgehen, diese erzeugt mit zwei weiteren TCP-Stack Features die du nicht so einfach per GUI oder PowerShell abschalten kannst, in manchen Situationen für ~3 Minuten einen TCP Deadlock. 🤢
die vielen einstellmöglichkeiten sind ja nicht ohne grund da
Setzt dich gut hin ... leider die Meisten, zumindest aus heutiger Sicht gesehen. 😡aber da jetzt wochen und Monate an zeit verplembern um das selber rauszufinden was welche einstellung macht?
Die nervigen Sprüche der Kunden bez. "aber wir haben doch eigentlich einen Ferrari und keinen Trabbi gekauft" anzuhören ist aber auch nicht besser.Beste Grüsse aus BaWü
Alex
ich hab mal gehört, das Flusskontrolle nur im alleräußersten Notfall angemacht werden sollte, falls wegen irgendwelchen Netzwerkproblemen zuviele Pakete verloren gehen, bremmst die Flusskontrolle das alles so ein dass die pakete nicht mehr verloren gehen...
Was mir noch aufgefallen ist - bei einem Switch Embedded Teaming mit 10G Netzwerkkarten - da mussten wir den lastenausgleichsmodus auf HyperVPort umstellen statt auf Dynamic, sonst hatten wir immer wieder recht viele TCP ReTransmissions unserer VMs was man auch gut über Wireshark gesehen hatte
irgendwie ist der ganze Server 2019 richtiger mist finde ich...hoffe es geht da nur nicht mir so
also meinst du - alles was Offload ist, Flusssteuerung und Interrupt steuerung direkt abschalten? :D
Was mir noch aufgefallen ist - bei einem Switch Embedded Teaming mit 10G Netzwerkkarten - da mussten wir den lastenausgleichsmodus auf HyperVPort umstellen statt auf Dynamic, sonst hatten wir immer wieder recht viele TCP ReTransmissions unserer VMs was man auch gut über Wireshark gesehen hatte
irgendwie ist der ganze Server 2019 richtiger mist finde ich...hoffe es geht da nur nicht mir so
also meinst du - alles was Offload ist, Flusssteuerung und Interrupt steuerung direkt abschalten? :D
Moin Assassin,
Ja, ist auch eine Art Überlaststeuerung, aber davon gibt es beim TSC-Stack noch einige mehr und die beissen sich eben gelegentlich.
Das ist interessant, habe ich noch nicht darauf geachtet, danke für die Info.
Nein Assassin, mit diesem Problem bist du ganz sicher nicht alleine, siehe wie oft dieser Beitrag bisher schon aufgerufen wurde. 😉
Ja, bitte, danke.
Und noch was ganz wichtiges, bitte die Sendepuffer der physikalischen NIC's auf 256K setzen und nicht höher, die Empfangspuffer kannst du hingegen auf max. setzen, sprich 2048K bei 1G und 4096K bei 10G.
Wenn die Sendepuffer des Senders (Server) grüsser sind wie die Empfangspuffer des Empfängers (Client), dann kommt es bei grösseren Datentransfers sehr oft vor, dass der Server den Client schlichtweg mit Daten quasi überflutet.
Wenn du dann noch einen asynchronen Linkspeed hast, sprich Server 10G und Clients 1G, dann kannst du bei einem Grösseren Datentransfer vom Server zum Client, per WireShark 1A beobachten, wie ständig der Client wegen vollgelaufenem Empfangspuffer absäuft. 😬 Wenn der Sendepuffer des Server < oder = dem Empfangspuffer des Clients ist, passiert dieser Mist nicht und der Datentransfer ist viel schneller und stabiler.
Ähm ....
Das hört sich übrigens, wenn ich genauer darüber nachdenke, genau nach diesem Problem an. 😉
Beste Grüsse aus BaWü
Alex
ich hab mal gehört, das Flusskontrolle nur im alleräußersten Notfall angemacht werden sollte, falls wegen irgendwelchen Netzwerkproblemen zuviele Pakete verloren gehen, bremmst die Flusskontrolle das alles so ein dass die pakete nicht mehr verloren gehen...
Ja, ist auch eine Art Überlaststeuerung, aber davon gibt es beim TSC-Stack noch einige mehr und die beissen sich eben gelegentlich.
Was mir noch aufgefallen ist - bei einem Switch Embedded Teaming mit 10G Netzwerkkarten - da mussten wir den lastenausgleichsmodus auf HyperVPort umstellen statt auf Dynamic, sonst hatten wir immer wieder recht viele TCP ReTransmissions unserer VMs was man auch gut über Wireshark gesehen hatte
Das ist interessant, habe ich noch nicht darauf geachtet, danke für die Info.
irgendwie ist der ganze Server 2019 richtiger mist finde ich...hoffe es geht da nur nicht mir so
Nein Assassin, mit diesem Problem bist du ganz sicher nicht alleine, siehe wie oft dieser Beitrag bisher schon aufgerufen wurde. 😉
also meinst du - alles was Offload ist, Flusssteuerung und Interrupt steuerung direkt abschalten? :D
Ja, bitte, danke.
Und noch was ganz wichtiges, bitte die Sendepuffer der physikalischen NIC's auf 256K setzen und nicht höher, die Empfangspuffer kannst du hingegen auf max. setzen, sprich 2048K bei 1G und 4096K bei 10G.
Wenn die Sendepuffer des Senders (Server) grüsser sind wie die Empfangspuffer des Empfängers (Client), dann kommt es bei grösseren Datentransfers sehr oft vor, dass der Server den Client schlichtweg mit Daten quasi überflutet.
Wenn du dann noch einen asynchronen Linkspeed hast, sprich Server 10G und Clients 1G, dann kannst du bei einem Grösseren Datentransfer vom Server zum Client, per WireShark 1A beobachten, wie ständig der Client wegen vollgelaufenem Empfangspuffer absäuft. 😬 Wenn der Sendepuffer des Server < oder = dem Empfangspuffer des Clients ist, passiert dieser Mist nicht und der Datentransfer ist viel schneller und stabiler.
Ähm ....
Was mir noch aufgefallen ist - bei einem Switch Embedded Teaming mit 10G Netzwerkkarten - da mussten wir den lastenausgleichsmodus auf HyperVPort umstellen statt auf Dynamic, sonst hatten wir immer wieder recht viele TCP ReTransmissions unserer VMs was man auch gut über Wireshark gesehen hatte face-confused
face-confusedDas hört sich übrigens, wenn ich genauer darüber nachdenke, genau nach diesem Problem an. 😉
Beste Grüsse aus BaWü
Alex
ist nicht standardmäßig bei allen Intel karten (egal ob 1G oder 10G) als sende und empfangspuffer 512 eingestellt? hatte da zumindest noch nie was anderes gesehen.
Bei den 10G karten die im Switch Embedded Team hängen für den Cluster für die VMs, hatte ich bereits den Empfangpufer jeder Karte auf 4096 angehoben, den Sendepuffer auf 512 belassen.
Dennoch hatte ich halt bei einem Dynamischen Lastenausgleich immer wieder paketverluste, also hab ich das Team dann auf HyperVPort umgestellt. seit dem läufts.
Set-VMSwitchTeam -Name "SET vSwitch" -LoadBalancingAlgorithm HyperVPort
Bei den 10G karten die im Switch Embedded Team hängen für den Cluster für die VMs, hatte ich bereits den Empfangpufer jeder Karte auf 4096 angehoben, den Sendepuffer auf 512 belassen.
Dennoch hatte ich halt bei einem Dynamischen Lastenausgleich immer wieder paketverluste, also hab ich das Team dann auf HyperVPort umgestellt. seit dem läufts.
Set-VMSwitchTeam -Name "SET vSwitch" -LoadBalancingAlgorithm HyperVPort
1
Moin Assassin,
Nein, leider ist es eben nicht überall der Fall. Gerade bei den 1G NIC's sind die Empfangspuffer, zumindest bei Intel, per default auf 256K gesetzt und die Sendepuffer auf 512K. ☹ Bei einer 10G hingegen, sind beide Puffer per default auf 512K gesetzt.
Die Sendepuffer würde ich sogar noch auf 256K reduzieren, dadurch fährst du mit der NIC den 1G Clients mit ihren 256K Empfangspuffer nicht so sehr ans Bein. Oder du klapperst alle Clients ab und stellst deren Empfangspuffer auf 2048K ein.
Das ist ein wirklich sehr interessanter Hinweis, danke. 👍👍👍
Ich habe mich ehrlich gesagt bisher noch nicht tiefer mit den Load Balancing Algorithmen der vSwitche befasst , habe dies aber gestern nachgeholt. Und ja, ich sehe beim dynamischen Modus direkt ein Verfahren, dass mir ehrlich gesagt etwas sorge bereitet.
Und zwar die Geschichte mit der Quell MAC Übersetzung.
Citrix hat hierzu eine ganz gute Doku gemacht.
https://support.citrix.com/article/CTX224494
Hmm, das mit dem "source MAC address replacement" sieht für mich irgendwie nach einem möglichen Flaschenhals aus. 🤔
Ausserdem verursacht die Übersetzung bestimmt zusätzliche Übertragungskosten.
Ich habe gestern Abend gleich ein Kundensystem von dynamisch auf HyperVPort umgestellt und bin schon extremst auf das heutige Feedback des Kunden gespannt.
Beste Grüsse aus BaWü
Alex
ist nicht standardmäßig bei allen Intel karten (egal ob 1G oder 10G) als sende und empfangspuffer 512 eingestellt? hatte da zumindest noch nie was anderes gesehen.
Nein, leider ist es eben nicht überall der Fall. Gerade bei den 1G NIC's sind die Empfangspuffer, zumindest bei Intel, per default auf 256K gesetzt und die Sendepuffer auf 512K. ☹ Bei einer 10G hingegen, sind beide Puffer per default auf 512K gesetzt.
Bei den 10G karten die im Switch Embedded Team hängen für den Cluster für die VMs, hatte ich bereits den Empfangpufer jeder Karte auf 4096 angehoben, den Sendepuffer auf 512 belassen.
Die Sendepuffer würde ich sogar noch auf 256K reduzieren, dadurch fährst du mit der NIC den 1G Clients mit ihren 256K Empfangspuffer nicht so sehr ans Bein. Oder du klapperst alle Clients ab und stellst deren Empfangspuffer auf 2048K ein.
Dennoch hatte ich halt bei einem Dynamischen Lastenausgleich immer wieder paketverluste, also hab ich das Team dann auf HyperVPort umgestellt. seit dem läufts.
Set-VMSwitchTeam -Name "SET vSwitch" -LoadBalancingAlgorithm HyperVPort
Set-VMSwitchTeam -Name "SET vSwitch" -LoadBalancingAlgorithm HyperVPort
Das ist ein wirklich sehr interessanter Hinweis, danke. 👍👍👍
Ich habe mich ehrlich gesagt bisher noch nicht tiefer mit den Load Balancing Algorithmen der vSwitche befasst , habe dies aber gestern nachgeholt. Und ja, ich sehe beim dynamischen Modus direkt ein Verfahren, dass mir ehrlich gesagt etwas sorge bereitet.
Und zwar die Geschichte mit der Quell MAC Übersetzung.
Citrix hat hierzu eine ganz gute Doku gemacht.
https://support.citrix.com/article/CTX224494
Hmm, das mit dem "source MAC address replacement" sieht für mich irgendwie nach einem möglichen Flaschenhals aus. 🤔
Ausserdem verursacht die Übersetzung bestimmt zusätzliche Übertragungskosten.
Ich habe gestern Abend gleich ein Kundensystem von dynamisch auf HyperVPort umgestellt und bin schon extremst auf das heutige Feedback des Kunden gespannt.
Beste Grüsse aus BaWü
Alex
Moin Alex, hast du schon feedback von deinem Kunden erhalten jetzt nach der umstellung auf HyperVPort?
und stimmt, die ganzen 1G karten haben 256K Empfangspuffer und 512K Sendepuffer. Aber damit hatte ich bisher eigentlich noch nie probleme. Das heißt ja nicht das er 512K große Pakete schickt, die den Puffer des gegenübers direkt überfluten würden.
Ich denke bzw. Hoffe mal, das Intel halbwegs weiß, was die da tun, also mit den Puffergrößen warum die das so voreingestellt haben ^^
beste grüße - David
und stimmt, die ganzen 1G karten haben 256K Empfangspuffer und 512K Sendepuffer. Aber damit hatte ich bisher eigentlich noch nie probleme. Das heißt ja nicht das er 512K große Pakete schickt, die den Puffer des gegenübers direkt überfluten würden.
Ich denke bzw. Hoffe mal, das Intel halbwegs weiß, was die da tun, also mit den Puffergrößen warum die das so voreingestellt haben ^^
beste grüße - David
Moin David,
Nein, ich habe noch kein Feedback bekommen, es gab jedoch seitens dieses Kunden Gestern aber auch keine Klage, sprich doch eine Art Feedback. 😜 Ich frage heute mal nach.
+- doch, und zwar ganz krass, wenn ein Server (10G und am besten 4M Sendepuffer 🤪) etwas grösseres an einen Client (1G / 512K Empfangspuffer) sendet. Wenn es nun während dieser Übertragung auf der Strecke zu einer Störung/Übelastsituation kommt, dann läuft beim Server der Sendepuffer hoch und wenn anschliessend die Überlastsituation, z.B. durch eine Sendepause quasi behoben ist, geht der Server her und feuert seinen gesamten Puffer auf einen Rutsch/Sequenz Richtung des Clients los. Dieser kann mit seinen 512K Empfangspuffer nicht mal annähernd gegen die 4M des Servers ankommen, verschluckt sich und es kommt zur nächsten Überlastsituation und so geht das Spielchen dann bis zum Ende der Übertragung weiter. 🤢
Vertrauen ist gut, Kontrolle ist besser. 😉
Beste Grüsse aus BaWü
Alex
Moin Alex, hast du schon feedback von deinem Kunden erhalten jetzt nach der umstellung auf HyperVPort?
Nein, ich habe noch kein Feedback bekommen, es gab jedoch seitens dieses Kunden Gestern aber auch keine Klage, sprich doch eine Art Feedback. 😜 Ich frage heute mal nach.
und stimmt, die ganzen 1G karten haben 256K Empfangspuffer und 512K Sendepuffer. Aber damit hatte ich bisher eigentlich noch nie probleme. Das heißt ja nicht das er 512K große Pakete schickt, die den Puffer des gegenübers direkt überfluten würden.
+- doch, und zwar ganz krass, wenn ein Server (10G und am besten 4M Sendepuffer 🤪) etwas grösseres an einen Client (1G / 512K Empfangspuffer) sendet. Wenn es nun während dieser Übertragung auf der Strecke zu einer Störung/Übelastsituation kommt, dann läuft beim Server der Sendepuffer hoch und wenn anschliessend die Überlastsituation, z.B. durch eine Sendepause quasi behoben ist, geht der Server her und feuert seinen gesamten Puffer auf einen Rutsch/Sequenz Richtung des Clients los. Dieser kann mit seinen 512K Empfangspuffer nicht mal annähernd gegen die 4M des Servers ankommen, verschluckt sich und es kommt zur nächsten Überlastsituation und so geht das Spielchen dann bis zum Ende der Übertragung weiter. 🤢
Ich denke bzw. Hoffe mal, das Intel halbwegs weiß, was die da tun, also mit den Puffergrößen warum die das so voreingestellt haben ^^
Vertrauen ist gut, Kontrolle ist besser. 😉
Beste Grüsse aus BaWü
Alex
Gut das TCP Pakete in der hinsicht "selbstheilend" sind wenn beim überlaufen etwas "verschweppert" wird und dadurch verschwindet ^^
denke mal, dass bei nem TCP strom das da zumindest etwas ausgeglichen wird und nur die übertragungsrate etwas zurück geht. klar die Latenz steigt dadurch, aber bei den heutigen geschwindigkeiten dürfte das doch kaum ins gewicht fallen, oder?
ich erlebe viel häufiger mit, dass alte SPS anlagen die nur mit 10MBits oder doch schon mit 100MBits ans riesige Firmennetz angebunden werden und man sich dann wundert, warum es da soviele Paketverluste gibt...wenn es da im Netz nen haufen Broadcast gibt, sind die kleinen miniswitche doch auch schon hart an der Kotzgrenze weil die nur noch mit Paket verwefen beschäftigt sind - welche garnicht an die adressiert waren, aber eben durch den Broadcast an der Schnittstelle angekommen sind....also so scheint es mir zumindest auch manchmal zu sein.
denke mal, dass bei nem TCP strom das da zumindest etwas ausgeglichen wird und nur die übertragungsrate etwas zurück geht. klar die Latenz steigt dadurch, aber bei den heutigen geschwindigkeiten dürfte das doch kaum ins gewicht fallen, oder?
ich erlebe viel häufiger mit, dass alte SPS anlagen die nur mit 10MBits oder doch schon mit 100MBits ans riesige Firmennetz angebunden werden und man sich dann wundert, warum es da soviele Paketverluste gibt...wenn es da im Netz nen haufen Broadcast gibt, sind die kleinen miniswitche doch auch schon hart an der Kotzgrenze weil die nur noch mit Paket verwefen beschäftigt sind - welche garnicht an die adressiert waren, aber eben durch den Broadcast an der Schnittstelle angekommen sind....also so scheint es mir zumindest auch manchmal zu sein.
mal wieder hoch holen hier...gibts was neues in sachen Tuning-Befehle?
@MysticFoxDE, weißt du, ob beim Server 2022 einiges besser gemacht wurde? oder ist alles genauso wild geblieben wie beim Server 2019?
Eigentlich müsste MS den Server 2022 als Kostenloses Upgrade zum 2019er anbieten soviel mist wie hier gemacht wurde mit der 2019er Version
habe mir eben nochmal einen thread wegen der CPU last anzeige und dem Taskmanager angeschaut...das verhalten ist schon seit Vista so, das MS da vom Baseclock ausgeht, nicht vom Realen Takt. Auch wird der echte takt auch nur berechnet...darum kann da auch manchmal 7Ghz da stehen xD
richtig lustig wird es, wenn du den energie-spar plan bearbeitest und als maximale CPu leistung mal 50% angibst - damit taktet die CPU nicht mehr so hoch, und damit erreicht man lt. Taskmanager auch nie mehr 100% CPU last...
@MysticFoxDE, weißt du, ob beim Server 2022 einiges besser gemacht wurde? oder ist alles genauso wild geblieben wie beim Server 2019?
Eigentlich müsste MS den Server 2022 als Kostenloses Upgrade zum 2019er anbieten soviel mist wie hier gemacht wurde mit der 2019er Version
habe mir eben nochmal einen thread wegen der CPU last anzeige und dem Taskmanager angeschaut...das verhalten ist schon seit Vista so, das MS da vom Baseclock ausgeht, nicht vom Realen Takt. Auch wird der echte takt auch nur berechnet...darum kann da auch manchmal 7Ghz da stehen xD
richtig lustig wird es, wenn du den energie-spar plan bearbeitest und als maximale CPu leistung mal 50% angibst - damit taktet die CPU nicht mehr so hoch, und damit erreicht man lt. Taskmanager auch nie mehr 100% CPU last...
Moin David,
leider ja und zu dem ganzen Windows-Tuning kommt bei aktuellen Systemen auch noch die BIOS-Optimierung hinzu, sonst hast du beim RAM evtl. nur ~ 30% oder noch weniger, von der möglichen Performance. 🤢
Ausserdem ist die RAM Performance der aktuellen Windows Systeme ist eh zum 🤮, vor allem bei zufälligen Zugriffen auf kleine Datenblöcke.
Ich habe vor Wochen die CT aktiviert, damit die mich beim „Aufarbeiten“ des Murkses etwas unterstützen, bisher ist aus dieser Richtung aber leider noch nicht viel geschehen.
😧 … besser … 😂🤣😂🤣 … der war gut, nein das kann ich gemäss dem was ich bisher gesehen habe leider nicht behaupten.
Der Murks aus dem 2019er ist im besten Fall 1:1 auch in den 2022er übernommen worden und im schlimmsten Fall, wurde dieser noch etwas verschlimmbessert. 😞
Ähm kostenlos … du meinst wohl mit einer ordentlichen Schmerzensgeldbeigabe. 😉
Sprich, wenn die untere CPU 30% Ihrer möglichen Leistung erreicht hat, zeigt der Taskmanager eine Auslastung von 100% an und über die Leistungsüberwachung siehst du eine CPU-Auslastung von bis zu 328%. 😵🤪
Sprich, der Taskmanager taugt im Bereich der CPU-Auslastungsanalyse bei modernen CPU’s, stellenweise nicht mal mehr für eine sehr grobe Auslastungseinschätzung. 😡
Sprich, ich kauf mir einen neuen Ferrari bei dem auf dem Tacho max. 80 km/h drauf stehen und anstellen den fehlerhaften Tacho zu tauschen, lasse ich den ganzen Karren auf max. 80 km/h drosseln, damit dieser ja nicht schneller fährt als der vermurkste Tacho anzeigen kann. 🙃
Jetzt mal im Ernst, wer würde so einen Murks bei einem Ferrari akzeptieren. 🤨
Und beim Microsoft nimmt man das seit Jahren einfach so hin. 😔
Falls du die Systemperformance eines Intel Servers unter Windows so richtig in den Keller fahren möchtest, dann musst du dafür lediglich im BIOS die P-STATES deaktivieren und die C-STATE Konfiguration so belassen wie sie ist.
Der Effekt ist absolut traumhaft, sprich Ferrari mit 80er Tacho + voll angezogene Handbremse. 🤪
Ich schau, dass ich die nächsten Wochen etwas mehr Details nachliefere.
Beste Grüsse aus BaWü
Alex
leider ja und zu dem ganzen Windows-Tuning kommt bei aktuellen Systemen auch noch die BIOS-Optimierung hinzu, sonst hast du beim RAM evtl. nur ~ 30% oder noch weniger, von der möglichen Performance. 🤢
Ausserdem ist die RAM Performance der aktuellen Windows Systeme ist eh zum 🤮, vor allem bei zufälligen Zugriffen auf kleine Datenblöcke.
Ich habe vor Wochen die CT aktiviert, damit die mich beim „Aufarbeiten“ des Murkses etwas unterstützen, bisher ist aus dieser Richtung aber leider noch nicht viel geschehen.
@MysticFoxDE, weißt du, ob beim Server 2022 einiges besser gemacht wurde? oder ist alles genauso wild geblieben wie beim Server 2019?
😧 … besser … 😂🤣😂🤣 … der war gut, nein das kann ich gemäss dem was ich bisher gesehen habe leider nicht behaupten.
Der Murks aus dem 2019er ist im besten Fall 1:1 auch in den 2022er übernommen worden und im schlimmsten Fall, wurde dieser noch etwas verschlimmbessert. 😞
Eigentlich müsste MS den Server 2022 als Kostenloses Upgrade zum 2019er anbieten soviel mist wie hier gemacht wurde mit der 2019er Version
Ähm kostenlos … du meinst wohl mit einer ordentlichen Schmerzensgeldbeigabe. 😉
habe mir eben nochmal einen thread wegen der CPU last anzeige und dem Taskmanager angeschaut...das verhalten ist schon seit Vista so, das MS da vom Baseclock ausgeht, nicht vom Realen Takt. Auch wird der echte takt auch nur berechnet...darum kann da auch manchmal 7Ghz da stehen xD
Sprich, wenn die untere CPU 30% Ihrer möglichen Leistung erreicht hat, zeigt der Taskmanager eine Auslastung von 100% an und über die Leistungsüberwachung siehst du eine CPU-Auslastung von bis zu 328%. 😵🤪
Sprich, der Taskmanager taugt im Bereich der CPU-Auslastungsanalyse bei modernen CPU’s, stellenweise nicht mal mehr für eine sehr grobe Auslastungseinschätzung. 😡
richtig lustig wird es, wenn du den energie-spar plan bearbeitest und als maximale CPu leistung mal 50% angibst - damit taktet die CPU nicht mehr so hoch, und damit erreicht man lt. Taskmanager auch nie mehr 100% CPU last...
Sprich, ich kauf mir einen neuen Ferrari bei dem auf dem Tacho max. 80 km/h drauf stehen und anstellen den fehlerhaften Tacho zu tauschen, lasse ich den ganzen Karren auf max. 80 km/h drosseln, damit dieser ja nicht schneller fährt als der vermurkste Tacho anzeigen kann. 🙃
Jetzt mal im Ernst, wer würde so einen Murks bei einem Ferrari akzeptieren. 🤨
Und beim Microsoft nimmt man das seit Jahren einfach so hin. 😔
Falls du die Systemperformance eines Intel Servers unter Windows so richtig in den Keller fahren möchtest, dann musst du dafür lediglich im BIOS die P-STATES deaktivieren und die C-STATE Konfiguration so belassen wie sie ist.
Der Effekt ist absolut traumhaft, sprich Ferrari mit 80er Tacho + voll angezogene Handbremse. 🤪
Ich schau, dass ich die nächsten Wochen etwas mehr Details nachliefere.
Beste Grüsse aus BaWü
Alex
Ja die P States sollte man an lassen und auf max performance stellen, sonst würde auch der TurboBoost nicht mehr funktionieren. C States können aus, weil Core-Parking braucht man nicht wirklich in nem Server - der soll ja max. performance bieten, gerade als Hypervisor
dachte MS hätte einige fehler korrigiert beim Server 2022
naja, irgendwie muss MS ja seine tolle Cloud besser vermarkten können...
ist wie beim Exchange und deren Sicherheitslücken, aber der Online Exchange hat natürlich keine Sicherheitslücken.
Aber es gibt halt einfach keine guten und Admin-Freundliche Alternativen
dachte MS hätte einige fehler korrigiert beim Server 2022
naja, irgendwie muss MS ja seine tolle Cloud besser vermarkten können...
ist wie beim Exchange und deren Sicherheitslücken, aber der Online Exchange hat natürlich keine Sicherheitslücken.
Aber es gibt halt einfach keine guten und Admin-Freundliche Alternativen
Moin...
Frank
irgendwie muss MS ja seine tolle Cloud besser vermarkten können...
deswgen rennt ein teil der MS Cloud ja unter Linux Frank
