Windows 11: Viele Verzeichnisse kopieren
Hallo
Es ist kein Problem das gelöst werden muss. Ich suche nach einem erfahrenen Profi, der mir das Problem und die Optionen erklärt
Ziel:
Kopieren von c:\beispiel\montag nach x:\backup\montag auf einem Win 11 PC. Die Quelle hat über 30'000 Unterverzeichnisse. Jedes Unterverzeichnis enthält keine bis 8 Dateien. Dateigrösse zwischen 7 KB bis 1800 KB.
X: ist ein Netzlaufwerk. Anbindung über Ethernet Cat6a und 1 GBit Netzwerkkarte. Keine anderen regelmässigen Netzwerkzugriffe auf diese Netzlaufwerk in dieser Zeit.
Umsetzung
Xcopy bricht ab. D.h. es werden zirka 2/3 kopiert
Robocopy läuft durch
Mit Powershell sieht so aus:
Frage
1.
Der Kopiervorgang dauert mehrere Stunden. Kann die Dauer des Vorganges optimiert werden?
Ich habe vor Jahren einen Artikel über Powershell 7 und Multithreading gelesen. Kann eine Aufgabe damit in parallel ablaufende Tasks aufgesplittet werden? Wenn ja, wie? Wenn ja, ist es wahrscheinlich das das hilft?
2.
In "Perfmon" sehe ich keine Auslastung der Netzwerkverbindung. Ich gehe davon aus, dass das Netzlaufwerk der entscheidende Faktor ("Flaschenhals") ist. D.h. HW / SW der Netzplatte kann das schreiben der Dateien nicht schneller erledigen. Wie könnte ich vorgehen, um das Problem tiefer zu untersuchen und damit zu dokumentieren?
Danke für jeden Praxistipp von euch Profis!
Beste Grüsse
Es ist kein Problem das gelöst werden muss. Ich suche nach einem erfahrenen Profi, der mir das Problem und die Optionen erklärt
Ziel:
Kopieren von c:\beispiel\montag nach x:\backup\montag auf einem Win 11 PC. Die Quelle hat über 30'000 Unterverzeichnisse. Jedes Unterverzeichnis enthält keine bis 8 Dateien. Dateigrösse zwischen 7 KB bis 1800 KB.
X: ist ein Netzlaufwerk. Anbindung über Ethernet Cat6a und 1 GBit Netzwerkkarte. Keine anderen regelmässigen Netzwerkzugriffe auf diese Netzlaufwerk in dieser Zeit.
Umsetzung
Xcopy bricht ab. D.h. es werden zirka 2/3 kopiert
xcopy /e /i c:\beispiel\montag x:\backup\montag
Robocopy läuft durch
robocopy c:\beispiel\montag x:\backup\montag /e /log:d:\calibrekopi.log
Mit Powershell sieht so aus:
$source = "c:\beispiel\montag"
$destination = "x:\backup\montag"
Copy-Item $source $destination -Recurse
Frage
1.
Der Kopiervorgang dauert mehrere Stunden. Kann die Dauer des Vorganges optimiert werden?
Ich habe vor Jahren einen Artikel über Powershell 7 und Multithreading gelesen. Kann eine Aufgabe damit in parallel ablaufende Tasks aufgesplittet werden? Wenn ja, wie? Wenn ja, ist es wahrscheinlich das das hilft?
2.
In "Perfmon" sehe ich keine Auslastung der Netzwerkverbindung. Ich gehe davon aus, dass das Netzlaufwerk der entscheidende Faktor ("Flaschenhals") ist. D.h. HW / SW der Netzplatte kann das schreiben der Dateien nicht schneller erledigen. Wie könnte ich vorgehen, um das Problem tiefer zu untersuchen und damit zu dokumentieren?
Danke für jeden Praxistipp von euch Profis!
Beste Grüsse
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7844807748
Url: https://administrator.de/contentid/7844807748
Ausgedruckt am: 21.11.2024 um 14:11 Uhr
9 Kommentare
Neuester Kommentar
Hi.
Da Du uns die Quelle verschweigst, schmeiß ichs trotzdem mal in den Raum:
## SMB CLIENT OPTIMIZATION
## SMB SERVER OPTIMIZATION
Vielleicht hilft es.
Gruß
Der Kopiervorgang dauert mehrere Stunden. Kann die Dauer des Vorganges optimiert werden?
Ich habe die Erfahrung gemacht, dass bei so einem (großen) Kopiervorgang die Optimierung der SMB Konfig ordentlich Boost gibt. Ab Server 2019 lohnt sich die Optimierung. Allerdings würde ich das nur temporär für diesen Vorgang setzen, da auch die Sicherheit darunter leidet.Da Du uns die Quelle verschweigst, schmeiß ichs trotzdem mal in den Raum:
## SMB CLIENT OPTIMIZATION
Set-SmbClientConfiguration -DirectoryCacheLifetime 0
Set-SmbClientConfiguration -EnableBandwidthThrottling $false
Set-SmbClientConfiguration -FileInfoCacheLifetime 0
Set-SmbClientConfiguration -FileNotFoundCacheLifetime 0
Set-SmbClientConfiguration -WindowSizeThreshold 1
Set-SmbClientConfiguration -EnableLargeMtu $true
Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 4
Set-SmbClientConfiguration -MaxCmds 100
Set-SmbClientConfiguration -EnableSecuritySignature $false
Set-SmbClientConfiguration -RequireSecuritySignature $false
## SMB SERVER OPTIMIZATION
Set-SmbServerConfiguration -CachedOpenLimit 0
Set-SmbServerConfiguration -EnableLeasing $false
Set-SmbServerConfiguration -EnableMultiChannel $false
Set-SmbServerConfiguration -MaxChannelPerSession 32
Set-SmbServerConfiguration -MaxMpxCount 2048
Set-SmbServerConfiguration -MaxThreadsPerQueue 40
Set-SmbServerConfiguration -MaxWorkItems 8192
Set-SmbServerConfiguration -AsynchronousCredits 2048
Set-SmbServerConfiguration -TreatHostAsStableStorage $true
Set-SmbServerConfiguration -EnableSecuritySignature $false
Set-SmbServerConfiguration -RequireSecuritySignature $false
Vielleicht hilft es.
Gruß
Deine Frage zielt vermutlich auf das Netzlaufwerk
Yes.NAS der Marke "Synology"
Auch hier kannst Du die/etc/samba/smb.conf
Cooler Name. Das erinnert mich an die Zeiten von Config.sys und himem.sys face-wink
.. hat verstanden Gruß
Hi,
Bzgl Multithreading:
Powershell ist multithreading-fähig.
Siehe:
https://gist.github.com/aconn21/946c702cfcc08d10e1c0984535765ae3
Speziell in diesem Anwendungsbereich - Copy von NAS zu X - ist das aber sinnlos. Das Bottleneck liegt hier nicht in der Verarbeitung sondern in der Bandbreite, denn dein NAS gibt einfach nicht mehr als xyz MB/s. Genauso was das Netzwerk angeht, wenn du nicht gerade überall eine 10GE-Leitung anstehen hast.
Ein Bsp aus meiner Umgebung:
Das Bottleneck ist hier das Netzwerk, denn die Platten würden ein pasr MB mehr schaffen.
Bzgl Multithreading:
Powershell ist multithreading-fähig.
Siehe:
https://gist.github.com/aconn21/946c702cfcc08d10e1c0984535765ae3
Speziell in diesem Anwendungsbereich - Copy von NAS zu X - ist das aber sinnlos. Das Bottleneck liegt hier nicht in der Verarbeitung sondern in der Bandbreite, denn dein NAS gibt einfach nicht mehr als xyz MB/s. Genauso was das Netzwerk angeht, wenn du nicht gerade überall eine 10GE-Leitung anstehen hast.
Ein Bsp aus meiner Umgebung:
- 2 Synology NAS, 2x1GB jeweils im Teaming
- 2,5GE-Switch aber der Rest ist nur 1GE
- Robocopy von A nach B max 112 MB/s in 1 Thread. Dito in mehreren Threads.
Das Bottleneck ist hier das Netzwerk, denn die Platten würden ein pasr MB mehr schaffen.
schade. rsync schonmal getestet?
Zitat von @Kraemer:
Ein häufiger Lösungsansatz ist, die Daten vorher in ein Archiv zu packen (7Zip bietet sich da an) und dann erst zu kopieren.
Ein häufiger Lösungsansatz ist, die Daten vorher in ein Archiv zu packen (7Zip bietet sich da an) und dann erst zu kopieren.
Ich sehe hier keinen Vorteil, sondern eine Verschlimmerung. Auch in einem 7z-Container oder ähnlichem, müssen die Daten erst vom NAS gelesen werden und dann erst noch in den Container. Das Ganze geht nicht direkt. Normalerweise öffnet jemand sein 7-zip am PC, markiert die Daten im Datei-Explorer die in unserem Fall am NAS liegen und legt im schlechtesten Fall das Ziel für den Container am selben Netz-Laufwerk fest.
Was passiert:
- Zielcontainer wird am NAS angelegt
- Daten werden über das Netzwerk am PC cached
- Dann über das gleiche Netzwerk in den Container geschoben.
Im besch... äh schlechtesten Fall verdoppelt oder verdreifacht sich also die Zeit.
Zitat von @PeterGyger:
Wahrscheinlich ein Netzwerk Sachverhalt. D.h. SMB optimieren (Vorschlag von emm386) oder (irgendwann) die Netzhardware auf 10 GBit anheben.
Wahrscheinlich ein Netzwerk Sachverhalt. D.h. SMB optimieren (Vorschlag von emm386) oder (irgendwann) die Netzhardware auf 10 GBit anheben.
Bei allen Komponenten? Also auch am PC, Notebook und jedem kleinen Switch der da so herum gurkt. Die Kabel auch nicht zu vergessen. Du braucht mindestens CAT6A, besser aber CAT7.
Es hört sich immer einfacher an als es ist 🙉🤔
Moin,
bei vielen tausend Verzeichnissen und Dateien wirst Du da wenig optimierungsmöglichkeiten haben, selbst wenn man "SMB tuned". Denn alleine das lokale Filesystem wird dich durch den overhead der Dateizugriffe stark ausbremsen. Hinzu kommt daß natürlich viele kleine dateien den TCP-Stack von Windows dran hindern "richtig in Fahrt zu kommen". Da wird weder ein Gigabit noch ein Multi-Gigabit-Ethernet etwas dran ändern, weil die überhaupt nicht an die grenzen stoßen. Und für Jumbo-Packets sind die Dateien zu klein.
Mein lösung wäre, Die Dateien lokal auf ein extra Volume zu packen und das ins filesystem ander passenden Stelle zu hängen und dann das gesamte Volume als Image zu sichern. Das wird Dich von Stunden auf wenige Minuten broingen oder zumindest zu deutlich niedrigeren Backup-Zeiten führen.
lks
bei vielen tausend Verzeichnissen und Dateien wirst Du da wenig optimierungsmöglichkeiten haben, selbst wenn man "SMB tuned". Denn alleine das lokale Filesystem wird dich durch den overhead der Dateizugriffe stark ausbremsen. Hinzu kommt daß natürlich viele kleine dateien den TCP-Stack von Windows dran hindern "richtig in Fahrt zu kommen". Da wird weder ein Gigabit noch ein Multi-Gigabit-Ethernet etwas dran ändern, weil die überhaupt nicht an die grenzen stoßen. Und für Jumbo-Packets sind die Dateien zu klein.
Mein lösung wäre, Die Dateien lokal auf ein extra Volume zu packen und das ins filesystem ander passenden Stelle zu hängen und dann das gesamte Volume als Image zu sichern. Das wird Dich von Stunden auf wenige Minuten broingen oder zumindest zu deutlich niedrigeren Backup-Zeiten führen.
lks