4
Kopiervorgang von Share zu Client langsam
Hallo,
ich habe schon X Beiträge zu dieser Frage gelesen, aber nichts hat bisher geholfen.
Problem: der Kopiervorgang von einem Windows-Share auf einen Client dauert extrem lange. Das Netzwerk läuft über eine gemeinsame Arbeitsgruppe, kein AD.
Für eine 70 MB Datei dauert der Kopiervorgang Share -> Client ca. 45 Sekunden. Beim umgekehrten Weg Client -> Share geht es Ruckzuck, ca. 1 Sekunde.
Das Share liegt auf einer Windows Server 2019 Instanz. Auf dem Client läuft Windows 10 Professional, das Problem besteht bei mehreren Clients.
Habe mit iperf die Bandbreite gemessen:
- Client -> Server: ca. 1 Gbit/sec.
- Server -> Client: ca. 20 Mbits/sec
Die Bandbreite Share -> Client ist also extrem schlecht.
Laut diversen Beiträgen im Netz hilft es, das Auto-Tuning (was immer das genau ist) für IPv6 auszuschalten:
Habe das sowohl auf dem Client als auch auf dem Server probiert, hat aber nicht geholfen.
Habe ebenfalls mal testweise Windows Defender auf dem Client abgeschaltet, hat aber auch nichts gebracht. Sonst ist da keine Anti-Viren-Software.
Habt Ihr eine Idee, wie man da weitermachen kann?
Gruß
*EDIT*: Derselbe Kopiervorgang vom NAS -> Client geht fix. Das Problem scheint also beim Windows Server zu liegen.
ich habe schon X Beiträge zu dieser Frage gelesen, aber nichts hat bisher geholfen.
Problem: der Kopiervorgang von einem Windows-Share auf einen Client dauert extrem lange. Das Netzwerk läuft über eine gemeinsame Arbeitsgruppe, kein AD.
Für eine 70 MB Datei dauert der Kopiervorgang Share -> Client ca. 45 Sekunden. Beim umgekehrten Weg Client -> Share geht es Ruckzuck, ca. 1 Sekunde.
Das Share liegt auf einer Windows Server 2019 Instanz. Auf dem Client läuft Windows 10 Professional, das Problem besteht bei mehreren Clients.
Habe mit iperf die Bandbreite gemessen:
- Client -> Server: ca. 1 Gbit/sec.
- Server -> Client: ca. 20 Mbits/sec
Die Bandbreite Share -> Client ist also extrem schlecht.
Laut diversen Beiträgen im Netz hilft es, das Auto-Tuning (was immer das genau ist) für IPv6 auszuschalten:
netsh interface tcp set global autotuninglevel=disableHabe das sowohl auf dem Client als auch auf dem Server probiert, hat aber nicht geholfen.
Habe ebenfalls mal testweise Windows Defender auf dem Client abgeschaltet, hat aber auch nichts gebracht. Sonst ist da keine Anti-Viren-Software.
Habt Ihr eine Idee, wie man da weitermachen kann?
Gruß
*EDIT*: Derselbe Kopiervorgang vom NAS -> Client geht fix. Das Problem scheint also beim Windows Server zu liegen.
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: 451735
Url: https://administrator.de/contentid/451735
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
4 Kommentare
Neuester Kommentar
Das Share liegt auf einer Windows Server 2019 Instanz
- Wo? Remote über VPN oder virtualisiert (HyperV/VMWare/usw...)? Wenn virtuell, VMQ mal deaktiviert und Treiber bzw virtuelle Hardware der Netzwerkkarte geswitcht?
- Switches dazwischen?
- Schon mal Wireshark bemüht und nachgesehen ob TCP-Retransmits beim Download erfolgen (mögliche Hinweise auf Kabeldefekt oder MTU Problem)?
- Welche Settings hat die virtuelle NIC im Gast? Welche am HOST zum externen vSwitch?
Gruß wireguard
Zitat von @139708:
- Wo? Remote über VPN oder virtualisiert (HyperV/VMWare/usw...)? Wenn virtuell, VMQ mal deaktiviert und Treiber bzw virtuelle Hardware der Netzwerkkarte geswitcht?
- Switches dazwischen?
- Schon mal Wireshark bemüht und nachgesehen ob TCP-Retransmits beim Download erfolgen (mögliche Hinweise auf Kabeldefekt oder MTU Problem)?
- Welche Settings hat die virtuelle NIC im Gast? Welche am HOST zum externen vSwitch?
Weder VPN noch virtualisiert. Ist ein Netzwerk mit 10 Clients, Router, NAS und Windows Server Instanz.
Auf dem Weg zwischen Client und Server liegen zwei Switches S1 und S2 (+ Router). Die Switches hängen an Wanddosen. Ein zentraler Switch S1, in dem alles zusammenläuft. Der Server hängt an S2.
Folgendes habe ich bisher probiert:
- Server direkt an Wanddose anschließen, statt an S2
- Kabel ausgetauscht, welche S2 und Server verbinden.
Hat nichts gebracht.
Wireshark zeigt beim Download viele TCP-Retransmission, Out-Of-Order- und Dup Ack-Pakete an. Beim Upload (der ja sowieso keine Probleme macht) tauchen diese Pakete selten auf.
Da das Problem nur beim Download auftritt, hatte ich eigentlich Probleme mit Switch und Verkabelung ausgeschlossen. Wenn z.B. ein Kabel kaputt ist, würde das Problem ja in beide Richtungen auftauchen.
Moin,
Ansonsten kontrolliere auf dem Server, ob SMB Encrypting bzw. Signing aktiviert ist. Das kann den Kopiervorgang u.a. ausbremsen.
Gruß,
Dani
Auf dem Weg zwischen Client und Server liegen zwei Switches S1 und S2 (+ Router). Die Switches hängen an Wanddosen. Ein zentraler Switch S1, in dem alles zusammenläuft. Der Server hängt an S2.
Auf welchen Switch hängt das NAS?Ansonsten kontrolliere auf dem Server, ob SMB Encrypting bzw. Signing aktiviert ist. Das kann den Kopiervorgang u.a. ausbremsen.
Gruß,
Dani
Das ist jetzt etwas peinlich, aber am Ende habe ich einfach mal das Netzwerkkabel aus- und wieder eingesteckt.
Und siehe da: die Geschwindigkeit ist in beide Richtungen bei knapp 1Gbit/sec.
Scheint also am Kabel gelegen zu haben. Ich hatte CAT6 HAMA-Kabel von Mediamarkt verwendet (nicht die billigsten), die immer etwas schwergängig in die Buchse gehen (die Lasche über dem Stecker ist so lang, dass sie einen Widerstand beim Einstecken bildet).
Werde sicherheitshalber mal andere Kabel verwenden.
Wundern tut mich, dass ich ausschließlich beim Download Geschwindigkeitsprobleme hatte.
Und siehe da: die Geschwindigkeit ist in beide Richtungen bei knapp 1Gbit/sec.
Scheint also am Kabel gelegen zu haben. Ich hatte CAT6 HAMA-Kabel von Mediamarkt verwendet (nicht die billigsten), die immer etwas schwergängig in die Buchse gehen (die Lasche über dem Stecker ist so lang, dass sie einen Widerstand beim Einstecken bildet).
Werde sicherheitshalber mal andere Kabel verwenden.
Wundern tut mich, dass ich ausschließlich beim Download Geschwindigkeitsprobleme hatte.
