SMB langsam bei großer Anzahl an kleinen Dateien

[bjoern3003]

Ich habe tag täglich damit zu tun, eine große Anzahl an kleinen Dateien von meinem Arbeitsplatz (Windows) zu meinem Unraid System zu kopieren.

 

Dieser Transfer dauert leider mitunter einige Stunden. Mit steigender Anzahl an Dateien dauert es umso länger.

 

Aktuell läuft noch KEINE paritätsplatte mit. Es wird auch erstmal alles auf der NVME Cache Platte gespeichert und später mit dem Mover auf die große HDD kopiert.

 

Große Dateien einzelne Dateien nutzen die kabelgebundene 1GB Netzwerkverbindung voll aus. 

 

Gibt es Möglichkeiten, ohne auf irgendwelche Tools Drittanbieter zu wechseln, die Geschwindigkeit zu erhöhen. Ich brauche für diverse Programme die Möglichkeit, die Freigaben auch als Netzlaufwerk anzusprechen.

[saber1]

Bei vielen kleinen Dateien leider normal:

 

https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking/slow-smb-file-transfer

[MAM59]

völlig normal, da ist kein Kraut gegen gewachsen. SMB macht immer "komplette Transaktionen". Es werden die Daten transferiert, gespeichert, das Verzeichnis aktualisiert, der Cache entleert und erst dann übers LAN abgenickt.

Dieser Overhead fällt bei großen Dateien nicht auf, aber bei vielen kleinen ist er enorm sichtbar und störend.

Aber, er tritt eigentlich nur beim Schreiben auf, weil da die Verzeichnisse neu geschrieben werden müssen. Beim Lesen später kommen sie eigentlich aus dem (RAM)Cache.

Eventuell solltest Du noch das Plug In "Folder Caching" installieren und auf diese Verzeichnisse ansetzen.

 

But, its not a bug, its a feature....

 

[bjoern3003]

Es geht mir auch insbesondere um das schreiben. 

 

Stimmt bei großen Dateien fällt es nicht auf und ist auch "egal". Gerade musste ich wieder rund 32k Dateien mit gesamt 200MB übertragen. Das hat ne gute Stunde gebraucht.

 

Gibt es da keine Alternativen? 

[hawihoney]

44 minutes ago, bjoern3003 said:

Gibt es da keine Alternativen? 

 

An der Quelle packen, übertragen und am Ziel entpacken? Ob das etwas bringt kommt allerdings auf die Dateitypen an.

[MAM59]

Jo, winrar ist Dein Freund...
Aber auch nur wenn Du das Archiv nach Transfer direkt auf Unraid entpackst. So als cronjob oder ähnliches Edited March 19 by MAM59

[bjoern3003]

Das ist vom Workflow leider keine Lösung.

 

Produktiv ist was anderes. Ich teste jetzt mal eben Nextcloud als Docker mit einem lokalen Syncronisierungsclient.

[MAM59]

1 hour ago, bjoern3003 said:

Ich teste jetzt mal eben Nextcloud als Docker mit einem lokalen Syncronisierungsclient.

Viel Spaß 😁

Mit dem Overhead wirds dann so 3-5mal so lange dauern.

 

Der schnellste Filetransfer geht eigentlich immer noch mit FTP. Probier mal den CrushFTP Docker und FileZilla unter Windoof.

[bjoern3003]

Eigentlich nicht, denn ich habe die Daten dann Lokal liegen und der synchronisiert im Hintergrund. Mag sein, dass es tatsächlich länger dauert, aber ich bekomme davon produktiv nichts mit.

 

FTP geht wiegesagt nicht, da ich die Daten physisch oder als Netzlaufwerk lokal erreichbar haben muss.

[DataCollector]

41 minutes ago, bjoern3003 said:

Eigentlich nicht, denn ich habe die Daten dann Lokal liegen und der synchronisiert im Hintergrund. Mag sein, dass es tatsächlich länger dauert, aber ich bekomme davon produktiv nichts mit.

FTP geht wiegesagt nicht, da ich die Daten physisch oder als Netzlaufwerk lokal erreichbar haben muss.

 

Tja, das Problem ist eben daß der Zugriff auf viele kleine Dateien schon bei normalen Datenträgern ziemlich bremst.

SMB bremst dann noch zusätzlich. (Wie es dahingehend mit NFS aussieht weiß ich nicht.)

 

Vor kurzem deutet jemand an, daß er eine große Menge an Bildern gerne schnell durchklickern können wollte.

Auch dort mußte ich mitteilen, daß mir meine Erfahrung gezeigt hat, daß der Zugriff auf eine große Anzahl vergleichsweise kleiner Dateien eben per SMB ziemlich bremst.

Selbst ein paar (Windows) Batchläufe über die große Menge an Dateien läuft auf einem SMB Laufwerk weitaus langsamer, als auf einem lokalen Laufwerk. Diese Latenz stört mich auch, aber ich sehe keine (für mich) praktikable Lösung, wenn es sich eben nicht um wiederholdende und überschaubare Mengen an Dateien handelt.

 

Aus dem Grund kopiere ich vorab den notwendigen Teil (einige zehntausende Dateien) auf die virtuelle Disk meiner VM direkt um um dann bei dem Bearbeiten die Dateien, so schnell wie der Datenträger her gibt, vorliegen zu haben. Im Anschluß schiebe ich das Ergebnis wieder da hin, wo ich es nun haben will.

 

Wie auch schon hier angedeutet wurde (mit der Idee des Packens): Man kann es beschleunigen, wenn man die Sachen eben an Quelle und Ziel Vor-/nacharbeitet.

Alternativ vielleicht nicht direkt auf dei Dateien zugrifen, sondern eine Datenbank (wenige größere Dateien) mit den Informationen und eben nicht direkt auf den ganze Schwung Einzeldateien.

 

Man kann zwar auch überlegen eine maximal flotte Netzwerkverbindung (10GBLan, 40GBLan, 100GBLan) zu nutzen, doch das ändert an der Latenz nur sehr wenig, da die "Ping- & Reaktionszeiten" dabei auch nur in sehr begrenztem Maße flotter werden.

[MAM59]

46 minutes ago, DataCollector said:

Man kann zwar auch überlegen eine maximal flotte Netzwerkverbindung (10GBLan, 40GBLan, 100GBLan) zu nutzen, doch das ändert an der Latenz nur sehr wenig, da die "Ping- & Reaktionszeiten" dabei auch nur in sehr begrenztem Maße flotter werden.

Das ist ein Griff ins Klo. Das LAN ist hier gar nicht die Bremse, sondern das Abwarten müssen, bis die Platte alle Transaktionen (Daten schreiben, Verzeichnis updaten) beendet hat. Und da liegt es hauptsächlich am unterliegenden Filesystem und der Plattenhardware.

SMB selber "bremst" gar nicht so. Es ist eben der Zwang, dass eine Aktion "erfolgreich beendet" sein muß, bevor mit der nächsten begonnen werden kann.

Der Linux Kernel (und auch Windows) benutzen dagegen "asynch IO" Ansätze, aber das scheitert übers LAN, weil ja keine gegenseitige Kontrolle der Partner exisitiert. Im Extremfalle meint der Sender, die Daten wären am Ziel und der Empfänger schmiert ab, während er sie noch im RAM Cache hat.

Dann sind sie weg und alle zetern laut rum.

Deshalb "play it safe, play it sequential". Das macht NFS übrigens auch nicht anders.

 

Es gab im Laufe der Geschichte mehrere Versuche, das Problem zu eleminieren. Den Erfolg derselben kann man ja nun recht einfach erahnen :-)))

1 hour ago, bjoern3003 said:

FTP geht wiegesagt nicht, da ich die Daten physisch oder als Netzlaufwerk lokal erreichbar haben muss.

Versteh ich nicht, die liegen doch dann immer lokal bzw auf dem Server lokal.

 

Vielleicht erklärst Du uns doch mal, was das denn für dringliche Daten sind? Und wofür/womit sie immer verwendet werden müssen.

 

Dieses diffuse "viele" und "kleine" hilft nicht so recht weiter bei der Ideenfindung