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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 173284
Url: https://administrator.de/contentid/173284
Ausgedruckt am: 26.11.2024 um 07:11 Uhr
11 Kommentare
Neuester Kommentar
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
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.
Die NIC Kartentreiber sollten zwingend die aktuellsten von der Intel Seite sein ! NICHT die embeddeten von MS. Im Zweifel also updaten.
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 ?