11
Netzwerk Einbahnstraße
Hallo Gemeinde,
mir ist bei meinen virtuellen Maschinen im Nachhinein aufgefallen, daß der Kopiervorgang beim Kopieren großer Dateien fast zum Erliegen kommt.
Auf der Suche nach der Ursache des Problems, habe ich ein seltsames Verhalten beim Kopieren großer Dateien über LAN festgestellt, allerdings schon außerhalb der virtuellen Maschinen:
Kopiere ich im Explorer von Server A eine große ISO Datei von Server A auf Server B (Hyper-V Host), erreiche ich eine gute Geschwindigkeit von rund 115 MByte/Sek. Ebenso verhält es sich, wenn ich im Explorer von Server A die gleiche Datei von Server B auf Server A ziehe. Dabei ist die Prozessorlast an Server A sehr niedrig und die Prozessorlast an Server B ebenso.
Kopiere ich hingegen im Explorer von Server B (Hyper-V Host) die gleiche ISO von Server B auf Server A, erreiche ich nur rund 55 MByte/Sek.
Dabei steigt einer der vier Prozessorkerne im Taskmanager während des Kopiervorgangs auf fast 100% Prozessorlast an. In umgekehrter Richtung ist das auch der Fall.
Hier die Konfig von Server A:
SBS2011
2x QuadCore Xeon E5620 (2.40 GHz)
24GB DDR3 ECC RAM
2x Onboard Intel 82574L Gigabit
RAID1 Intel Onboard für OS
RAID 10 an 3ware RAID Controller für die Daten
Single HDD an Onboard SATA als Lokale Backupplatte
Konfig Server B:
Server 2008R2 (Hyper-V Host)
2x DualCore Xeon 5130 (2.00 GHz)
20GB DDR2 FB ECC RAM
2x Onboard Intel PRO 1000/EB Gigabit
RAID1 Intel Onboard für OS
RAID 10 an 3ware RAID Controller für die Daten
Single HDD an Onboard SATA als Lokale Backupplatte
LAN 1 von Server A und LAN 1 von Server B (Hyper-V Host) sind über ein GBit Switch im IP-Bereich 192.168.xxx.xxx verbunden und sind im Firmennetz.
LAN 2 von Server A und LAN 2 von Server B sind direkt über ein CAT5e Kabel (kein Crossover) im IP-Bereich 195.168.xxx.xxx miteinander verbunden.
Egal ob ich über 192.168.xxx.xxx (Switch) oder über 195.168.xxx.xxx (direkte LAN-Verbindung) kopiere, es ändert sich nichts.
Ich schließe somit also den Switch als Ursache aus.
Was könnte das Problem noch verursachen?
Ideen?
Gruß, DQ
mir ist bei meinen virtuellen Maschinen im Nachhinein aufgefallen, daß der Kopiervorgang beim Kopieren großer Dateien fast zum Erliegen kommt.
Auf der Suche nach der Ursache des Problems, habe ich ein seltsames Verhalten beim Kopieren großer Dateien über LAN festgestellt, allerdings schon außerhalb der virtuellen Maschinen:
Kopiere ich im Explorer von Server A eine große ISO Datei von Server A auf Server B (Hyper-V Host), erreiche ich eine gute Geschwindigkeit von rund 115 MByte/Sek. Ebenso verhält es sich, wenn ich im Explorer von Server A die gleiche Datei von Server B auf Server A ziehe. Dabei ist die Prozessorlast an Server A sehr niedrig und die Prozessorlast an Server B ebenso.
Kopiere ich hingegen im Explorer von Server B (Hyper-V Host) die gleiche ISO von Server B auf Server A, erreiche ich nur rund 55 MByte/Sek.
Dabei steigt einer der vier Prozessorkerne im Taskmanager während des Kopiervorgangs auf fast 100% Prozessorlast an. In umgekehrter Richtung ist das auch der Fall.
Hier die Konfig von Server A:
SBS2011
2x QuadCore Xeon E5620 (2.40 GHz)
24GB DDR3 ECC RAM
2x Onboard Intel 82574L Gigabit
RAID1 Intel Onboard für OS
RAID 10 an 3ware RAID Controller für die Daten
Single HDD an Onboard SATA als Lokale Backupplatte
Konfig Server B:
Server 2008R2 (Hyper-V Host)
2x DualCore Xeon 5130 (2.00 GHz)
20GB DDR2 FB ECC RAM
2x Onboard Intel PRO 1000/EB Gigabit
RAID1 Intel Onboard für OS
RAID 10 an 3ware RAID Controller für die Daten
Single HDD an Onboard SATA als Lokale Backupplatte
LAN 1 von Server A und LAN 1 von Server B (Hyper-V Host) sind über ein GBit Switch im IP-Bereich 192.168.xxx.xxx verbunden und sind im Firmennetz.
LAN 2 von Server A und LAN 2 von Server B sind direkt über ein CAT5e Kabel (kein Crossover) im IP-Bereich 195.168.xxx.xxx miteinander verbunden.
Egal ob ich über 192.168.xxx.xxx (Switch) oder über 195.168.xxx.xxx (direkte LAN-Verbindung) kopiere, es ändert sich nichts.
Ich schließe somit also den Switch als Ursache aus.
Was könnte das Problem noch verursachen?
Ideen?
Gruß, DQ
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: 173284
Url: https://administrator.de/contentid/173284
Ausgedruckt am: 04.11.2024 um 17:11 Uhr
11 Kommentare
Neuester Kommentar
Hallo DQ,
kannst du während des Kopierens von B nach A vom Server B festellen welcher Prozess die große Last produziert?
Ich vermute mal, dass der Virenscanner oder ähnliches Tool das Problem ist. Evtl. mal den Virenscanner abschalten und noch mal Probieren.
Gruß
Joachim
kannst du während des Kopierens von B nach A vom Server B festellen welcher Prozess die große Last produziert?
Ich vermute mal, dass der Virenscanner oder ähnliches Tool das Problem ist. Evtl. mal den Virenscanner abschalten und noch mal Probieren.
Gruß
Joachim
Hallo Joachim,
nach dem Leerlaufprozess mit ca. 70-80% ist explorer.exe der nachfolgende Prozess im Taskmanager mit 20-30% Auslastung, also 1/4 Prozessor.
Virenscanner ist auf beidern Servern deinstalliert.
Keine Änderung.
Gruß, DQ
nach dem Leerlaufprozess mit ca. 70-80% ist explorer.exe der nachfolgende Prozess im Taskmanager mit 20-30% Auslastung, also 1/4 Prozessor.
Virenscanner ist auf beidern Servern deinstalliert.
Keine Änderung.
Gruß, DQ
Hallo,
Gruß,
Peter
Zitat von @DonQuichote:
nach dem Leerlaufprozess mit ca. 70-80% ist explorer.exe der nachfolgende Prozess im Taskmanager mit 20-30% Auslastung, also 1/4
Prozessor.
Lass mal NetIO in beiden Richtungen und beiden Verbindungen laufen. Poste die Ergebnisse mal hier.nach dem Leerlaufprozess mit ca. 70-80% ist explorer.exe der nachfolgende Prozess im Taskmanager mit 20-30% Auslastung, also 1/4
Prozessor.
Gruß,
Peter
Hallo Peter,
netio123 gibt folgendes aus:
Server A = UDP Client, Server B = UDP Server:
NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 93596 KByte/s (1%) Tx, 71047 KByte/s (0%) Rx.
Packet size 2k bytes: 20599 KByte/s (0%) Tx, 13801 KByte/s (0%) Rx.
Packet size 4k bytes: 39470 KByte/s (0%) Tx, 23854 KByte/s (0%) Rx.
Packet size 8k bytes: 55740 KByte/s (0%) Tx, 36034 KByte/s (0%) Rx.
Packet size 16k bytes: 59624 KByte/s (0%) Tx, 56380 KByte/s (0%) Rx.
Packet size 32k bytes: 74289 KByte/s (0%) Tx, 62810 KByte/s (0%) Rx.
Done.
Server A = TCP Client, Server B = TCP Server:
NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 97003 KByte/s Tx, 82011 KByte/s Rx.
Packet size 2k bytes: 100250 KByte/s Tx, 94168 KByte/s Rx.
Packet size 4k bytes: 111146 KByte/s Tx, 111114 KByte/s Rx.
Packet size 8k bytes: 113336 KByte/s Tx, 108436 KByte/s Rx.
Packet size 16k bytes: 112534 KByte/s Tx, 109062 KByte/s Rx.
Packet size 32k bytes: 113229 KByte/s Tx, 110482 KByte/s Rx.
Done.
Server A = UDP Server, Server B = UDP Client:
NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 67467 KByte/s (0%) Tx, 89464 KByte/s (0%) Rx.
Packet size 2k bytes: 13167 KByte/s (0%) Tx, 20448 KByte/s (0%) Rx.
Packet size 4k bytes: 24275 KByte/s (0%) Tx, 39088 KByte/s (0%) Rx.
Packet size 8k bytes: 36412 KByte/s (0%) Tx, 54862 KByte/s (0%) Rx.
Packet size 16k bytes: 56019 KByte/s (0%) Tx, 59047 KByte/s (0%) Rx.
Packet size 32k bytes: 63325 KByte/s (0%) Tx, 72033 KByte/s (0%) Rx.
Done.
Server A = TCP Server, Server B = TCP Client:
NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 81250 KByte/s Tx, 94660 KByte/s Rx.
Packet size 2k bytes: 94847 KByte/s Tx, 100792 KByte/s Rx.
Packet size 4k bytes: 110873 KByte/s Tx, 109082 KByte/s Rx.
Packet size 8k bytes: 105995 KByte/s Tx, 112215 KByte/s Rx.
Packet size 16k bytes: 110017 KByte/s Tx, 113003 KByte/s Rx.
Packet size 32k bytes: 111214 KByte/s Tx, 111741 KByte/s Rx.
Done.
netio123 gibt folgendes aus:
Server A = UDP Client, Server B = UDP Server:
NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 93596 KByte/s (1%) Tx, 71047 KByte/s (0%) Rx.
Packet size 2k bytes: 20599 KByte/s (0%) Tx, 13801 KByte/s (0%) Rx.
Packet size 4k bytes: 39470 KByte/s (0%) Tx, 23854 KByte/s (0%) Rx.
Packet size 8k bytes: 55740 KByte/s (0%) Tx, 36034 KByte/s (0%) Rx.
Packet size 16k bytes: 59624 KByte/s (0%) Tx, 56380 KByte/s (0%) Rx.
Packet size 32k bytes: 74289 KByte/s (0%) Tx, 62810 KByte/s (0%) Rx.
Done.
Server A = TCP Client, Server B = TCP Server:
NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 97003 KByte/s Tx, 82011 KByte/s Rx.
Packet size 2k bytes: 100250 KByte/s Tx, 94168 KByte/s Rx.
Packet size 4k bytes: 111146 KByte/s Tx, 111114 KByte/s Rx.
Packet size 8k bytes: 113336 KByte/s Tx, 108436 KByte/s Rx.
Packet size 16k bytes: 112534 KByte/s Tx, 109062 KByte/s Rx.
Packet size 32k bytes: 113229 KByte/s Tx, 110482 KByte/s Rx.
Done.
Server A = UDP Server, Server B = UDP Client:
NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 67467 KByte/s (0%) Tx, 89464 KByte/s (0%) Rx.
Packet size 2k bytes: 13167 KByte/s (0%) Tx, 20448 KByte/s (0%) Rx.
Packet size 4k bytes: 24275 KByte/s (0%) Tx, 39088 KByte/s (0%) Rx.
Packet size 8k bytes: 36412 KByte/s (0%) Tx, 54862 KByte/s (0%) Rx.
Packet size 16k bytes: 56019 KByte/s (0%) Tx, 59047 KByte/s (0%) Rx.
Packet size 32k bytes: 63325 KByte/s (0%) Tx, 72033 KByte/s (0%) Rx.
Done.
Server A = TCP Server, Server B = TCP Client:
NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 81250 KByte/s Tx, 94660 KByte/s Rx.
Packet size 2k bytes: 94847 KByte/s Tx, 100792 KByte/s Rx.
Packet size 4k bytes: 110873 KByte/s Tx, 109082 KByte/s Rx.
Packet size 8k bytes: 105995 KByte/s Tx, 112215 KByte/s Rx.
Packet size 16k bytes: 110017 KByte/s Tx, 113003 KByte/s Rx.
Packet size 32k bytes: 111214 KByte/s Tx, 111741 KByte/s Rx.
Done.
Hast du irgend eine Packet Inspection Software / Firewall mit DPI drauf ?
Sygate Firewall bspw. hat das per Default nämlich an.
Laut dem Net-IO sieht eig. alles ziemlich gut aus
Sygate Firewall bspw. hat das per Default nämlich an.
Laut dem Net-IO sieht eig. alles ziemlich gut aus
Ou, da schreibt ein Fleißiger aus der Nachtschicht ...
Nein, nur die Windows Firewall ist drauf, sonst nichts.
Nein, nur die Windows Firewall ist drauf, sonst nichts.
Die NetIO Messung ist unsinnig oben da sie UDP verwendet was falsch ist und auf wenig Netzwerk Wissen schliessen lässt... 
CIFS Dienste verwenden TCP als Transportprotokoll (TCP 445) ! Wenn schon denn schon also mit einer TCP Encapsulation messen (-t Parameter !) und nochmal posten hier !
Die NIC Kartentreiber sollten zwingend die aktuellsten von der Intel Seite sein ! NICHT die embeddeten von MS. Im Zweifel also updaten.
CIFS Dienste verwenden TCP als Transportprotokoll (TCP 445) ! Wenn schon denn schon also mit einer TCP Encapsulation messen (-t Parameter !) und nochmal posten hier !Die NIC Kartentreiber sollten zwingend die aktuellsten von der Intel Seite sein ! NICHT die embeddeten von MS. Im Zweifel also updaten.
Zitat von @aqui:
Die NetIO Messung ist unsinnig oben da sie UDP verwendet was falsch ist und auf wenig Netzwerk Wissen schliessen lässt...
Die NetIO Messung ist unsinnig oben da sie UDP verwendet was falsch ist und auf wenig Netzwerk Wissen schliessen lässt...
Deshalb wende ich mich ja auch an die Community. Wenn ich alles wüsste, bräuchte ich ja nicht fragen ...
CIFS Dienste verwenden TCP als Transportprotokoll (TCP 445) ! Wenn schon denn schon also mit einer TCP Encapsulation messen
(-t Parameter !) und nochmal posten hier !
(-t Parameter !) und nochmal posten hier !
Die TCP Messung ist doch schon hier aufgeführt.
UDP habe ich der Vollständigkeit halber mitgemacht.
Die NIC Kartentreiber sollten zwingend die aktuellsten von der Intel Seite sein ! NICHT die embeddeten von MS. Im Zweifel also
updaten.
updaten.
Die installierten Netzwerktreiber sind die aktuellen von Intel, nicht die von Microsoft - auf beiden Servern.
Sorry, die TCP Werte sind beim Scrollen "verschütt" gegangen...
Die Werte zeigen generell einen konstanten TCP Transfer Wert über alle Packetgrößen von ~112 Mbyte/s ~890-900 Mbit/s und das bidirektional, was ein sehr guter Wert für ein GiG Netzwerk ist und auch erwartbar ist bei Intel NIC Hardware.
Lediglich wenn Server B Empfänger ist kommt es zu diesem Einbruch !
Es liegt also de facto nicht am Switch sondern einzig am Server B im Empfänger bzw. in dessen RX Zweig. Bleibt die Frage nach dem Grund....also obs physisch ist NIC, Treiber oder Stack bezogen TCP Stack.
Sind beides physische Server ?
Hast du die Chance alternativ eine andere NIC Hardware in Server B zu testen ?
Welches OS rennt darauf ?
Die Werte zeigen generell einen konstanten TCP Transfer Wert über alle Packetgrößen von ~112 Mbyte/s ~890-900 Mbit/s und das bidirektional, was ein sehr guter Wert für ein GiG Netzwerk ist und auch erwartbar ist bei Intel NIC Hardware.
Lediglich wenn Server B Empfänger ist kommt es zu diesem Einbruch !
Es liegt also de facto nicht am Switch sondern einzig am Server B im Empfänger bzw. in dessen RX Zweig. Bleibt die Frage nach dem Grund....also obs physisch ist NIC, Treiber oder Stack bezogen TCP Stack.
Sind beides physische Server ?
Hast du die Chance alternativ eine andere NIC Hardware in Server B zu testen ?
Welches OS rennt darauf ?
Allerdings nur wenn der Kopiervorgang aus dem Explorer von Server B gestartet wird.
Sind beides physische Server ?
Ja.
Hast du die Chance alternativ eine andere NIC Hardware in Server B zu testen ?
Ja. werde ich am Freitag machen. Erst dann bin ich wieder im Betrieb. Erhoffe mir aber nicht allzu viel davon, da die Geschwindigkeit bidirektional ja OK ist.
Wie gesagt, 100% Prozessorlast eines Cores beim Kopiervorgang im Explorer von Server B ... kritzekratze ... weiß nicht warum.
Welches OS rennt darauf ?
2008R2. Steht aber schon in meinem Anfangspost.
So, habe jetzt die Ursache gefunden - es war der Schreibcache des 3ware 9500S-4LP Raid-Controllers.
Ist scheinbar ein Bug im Treiber der 3Ware 95xx Serie unter 2008R2.
Nach jedem Neustart des Servers schaltet sich der Schreibcache bei diesem Controller aus.
In der Web-Console steht der Schreibcache nach dem Neustart immer noch auf "on", der Controller kriegt das aber scheinbar nicht mit.
Nach viel experimentieren hier die Lösung:
Beim Herunterfahren des Servers starte ich eine Batch-Datei über die Lokale Richtlinie (Computerkonfiguration/Windows-Einstellungenmit/Skripts (Start/Herunterfahren) dem Inhalt:
tw_cli /c0/u0 set cache=off quiet ( -> Schreibcache ausschalten)
Nur wenn der Schreibcache des Controllers vor dem Reboot über die CMD (CLI) deaktiviert wurde, läßt er sich nach dem Neustart über
tw_cli /c0/u0 set cache=on quiet (-> Schreibcache einschalten)
zuverlässig einschalten. Die Batch-Datei mit dem Einschaltbefehl starte ich dann ebenfalls über die lokale GPO beim Hochfahren des Servers.
Problem also gelöst!
Gruß u. Dank an die Helfer hier im Forum!
DQ
Ist scheinbar ein Bug im Treiber der 3Ware 95xx Serie unter 2008R2.
Nach jedem Neustart des Servers schaltet sich der Schreibcache bei diesem Controller aus.
In der Web-Console steht der Schreibcache nach dem Neustart immer noch auf "on", der Controller kriegt das aber scheinbar nicht mit.
Nach viel experimentieren hier die Lösung:
Beim Herunterfahren des Servers starte ich eine Batch-Datei über die Lokale Richtlinie (Computerkonfiguration/Windows-Einstellungenmit/Skripts (Start/Herunterfahren) dem Inhalt:
tw_cli /c0/u0 set cache=off quiet ( -> Schreibcache ausschalten)
Nur wenn der Schreibcache des Controllers vor dem Reboot über die CMD (CLI) deaktiviert wurde, läßt er sich nach dem Neustart über
tw_cli /c0/u0 set cache=on quiet (-> Schreibcache einschalten)
zuverlässig einschalten. Die Batch-Datei mit dem Einschaltbefehl starte ich dann ebenfalls über die lokale GPO beim Hochfahren des Servers.
Problem also gelöst!
Gruß u. Dank an die Helfer hier im Forum!
DQ
