extrem schlechte Performance bei Transfers von SMB Freigabe zu SMB Freigabe

[thor17]

Hallo!

Seit kurzem habe ich in meinem NAS (Ubuntu) zwei Speicherpools mit ZFS laufen. Beide sind über Samba freigegeben.
Wenn ich nun über meinen PC (verbunden über 4 NICs, bond-mode 0) etwas von einem in den anderen Pool kopieren/verschieben möchte, dann liegt die Geschwindigkeit gerademal bei um die 2-5MB/s.
Selbstredend, dass das völlig inakzeptabel ist. Die üblichen Sambatweaks habe ich bereits in der smb.conf vorgenommen.

[global]

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072

read raw = yes
write raw = yes
use sendfile = true
min receivefile size=131072
aio write size = 16384
aio read size = 16384
aio write behind = true

   strict sync = no
   sync always = no

Das Problem tritt nur beim Transfer zwischen Sambafreigaben auf. Wenn ich etwas vom NAS auf meine SSD im PC kopiere oder umgekehrt, dann liegt die Geschwindigkeit so bei ~200MiB/s. Das ist zwar auch nicht gerade das gelbe vom Ei, aber damit kann ich noch leben.
An der Netzwerkverbindung dürfte es nicht liegen, laut iperf ~3,9GBit/s.
Und wenn ich im Terminal direkt auf dem Server etwas kopiere, dann liegt die Geschwindigkeit bei etwa ~350MiB/s, also liegt's auch nicht am Dateisystem.

Was könnte ich noch machen, um dieses Problem zu lösen? Und bitte ratet mir nicht zu NFS

 

[besterino]

Warum jagst Du das denn überhaupt über SMB und nicht lokal? Ist evtl. Dein Client der Flaschenhals?

Kenne mich nicht total superduper mit SMB Transfers aus, aber wenn ich das richtig in Erinnerung habe und Du das über einen Client kopierst, zieht sich erst der Client die Daten von der einen Freigabe rüber und schickt sie dann wieder zurück auf den anderen Pool. Wenn dein Client dann z.B. keinen dual-gigabit link hat, führt das gerne zu schönen Paketstaus auf der Strecke... (Zum Beispiel gab es zur guten alten FTP-Zeit für ein ähnliches Scenario mit zwei Servern das Progrämmchen FlashFXP um damit zwei Server direkt den transfer managen zu lassen ohne Umweg über den Client).

- - - Updated - - -

Kann auch sein, dass das gleichzeitige Empfangen/Senden auf ein und der selben Strecke bei Linkaggregation zickt und fullduplex nicht mehr richtig funktioniert. Ich versuche bei sowas wenn dann immer lieber die beiden Shares über getrennte NICs anzusprechen. Aber am besten ist ehrlich gesagt aus meiner Sicht der lokale Transfer...

 

[thor17]

Um das, bequem, lokal zu erledigen, müsste ich X auf dem NAS installieren um dann Nautilus oder irgendeinen anderen Dateimanager nutzen zu können. Das würde ich aber gern vermeiden.

 

[gea]

Midnight Commander läuft auf der Console oder remote via Putty.

 

[besterino]

Jau, wenn man sich mit BSD/Linux/Solaris beschäftigt, sind Putty/SSH und ggf. Google Dein Freund, damit lässt sich alles von quasi überall sicher lösen... ggf. mit Hilfe von Google ;-)...

Schadet definitiv nicht, sich mit cp, mv, rsync, vi(m) & co. etwas auszukennen...

 

[thor17]

Na klar, wenn die Dateinamen 30 Zeichen und mehr haben und ich dann dutzende in verschiedene Ordner sortieren möchte, ist das mit dem Terminal natürlich total bequem...
Ich arbeite sehr viel mit dem Terminal, aber wenn es um derlei geht, nutze ich auch gern mal die Annehmlichkeiten eines grafischen Dateibrowsers...
Mal abgesehen davon, dass das eigentliche Problem ja damit dennoch nicht gelöst ist.

Man kann sich zwar mit Nautilus per SSH mit dem NAS verbinden, aber unverständlicherweise kopiert er dann trotzdem alles über das Netzwerk.

 

[fdsonne]

Wie viel Durchsatz schaffst du denn gleichzeitig, wenn du via iperf und Co. mal den Client in die Kommunikation involvierst, so wie du es auch mit dem Dateimanager machen würdest?
Die gesagten Werte beziehen sich ja alle samt auf "eine" Richtung. Entweder lokal am Server oder von/zum Client.

Was passiert, wenn du sowohl iperf Client als auch Server am laufen hast und zusätzlich deinen normalen Arbeitsclient einmal den iperf Server des SMB Servers und der iperf Client des SMB Servers den Server auf deinem Arbeitsclient anspricht? Also so, wie es sein würde, wenn du Daten vom Server über den Client zurück zum Server via SMB tranferieren würdest?

-> keine Ahnung, ob hier wirklich SMB direkt das Problem ist -> könnte natürlich. Aber für die Erörterung des Problems würde ich es an deiner Stelle mal versuchen weiter einzugrenzen. Bspw. Stichwort NFS ist dabei ein gutes. Versuch mal ein anderes Protokoll zu nutzen.
-> wie/was ist denn der Arbeitsclient genau? Windows? Linux? Je nachdem, wäre zum Beispiel noch interessant, ob da nicht im Hintergrund der Client selbst mit reinspuckt -> bspw. ein Filetransfer über SMB mit echtzeit Virusscan der angefassten Daten unter Windows -> müsste man checken, wie viel Durchsatz da geht, ggf. Virenscanner für die Arbeit ausschalten oder ähnliches...

 

[VirtuGuy]

Samba kann auch "Server Site Copy", aber ggf wird es von deinem Client OS nicht unterstützt.

https://wiki.samba.org/index.php/Server-Side_Copy

 

[thor17]

Hmm, wenn das stimmt was da steht, dann wird's wohl so sein.
Merkwürdig, dass das noch nicht im CIFS Client von Linux implementiert wurde.

 

[Digi-Quick]

Na klar, wenn die Dateinamen 30 Zeichen und mehr haben und ich dann dutzende in verschiedene Ordner sortieren möchte, ist das mit dem Terminal natürlich total bequem...
Ich arbeite sehr viel mit dem Terminal, aber wenn es um derlei geht, nutze ich auch gern mal die Annehmlichkeiten eines grafischen Dateibrowsers...

Ich versteh gerade dein Problem nicht:
- ssh auf dem Host aktivieren
- Putty starten
- unter "Window" "When window ist resized - change number of rows and columns" aktivieren
- via Putty (ssh) auf den Host verbinden
- das Putty Fenster auf Vollbild vergrössern
- Midnight commander starten
- sich über lange Datei und Verzeichnisnamen freuen

das reicht für alle lokalen Dateioperationen

 

[NTB]

Sein Problem ist, dass der Transfer auch von SMB zu SMB schneller gehen müsste, als mit 5 MB/s.

 

[thor17]

Sein Problem ist, dass der Transfer auch von SMB zu SMB schneller gehen müsste, als mit 5 MB/s.

Genauso sieht's aus


Ich weiß nicht, ob es an Unzulänglichkeiten Sambas liegt in Hinsicht auf Verbindungen über gebündelte NICs, denn wie ich las, gibt es über 10GBe NICs keine derartigen Probleme. Die Leute beschweren sich, dass die Daten nur mit 600MiB/s übertragen werden^^
Aber wie auch immer, ich hatte einfach angenommen, wenn ich das Geschwindigkeitsproblem nicht lösen kann, dann wäre evtl. serverside-copy ne Lösung, im Prinzip ja ohnehin die beste Variante, aber das wird eben vom Client nicht unterstützt.

 

[besterino]

Teste doch mal um Komplexität rauszunehmen, wie die Geschwindigkeit über nur einen einzelnen Link aussieht.

Wenn das schon nicht mit max-linkspeed fluppt, weisst Du immerhin, dass es (wahrscheinlich) nicht an der Portbündelung liegt. Dann würde ich aber trotzdem erst einmal der Sache ohne Portbündelung zu Leibe rücken, denn (vermutlich) wird dir 10gbe dann auch nicht ohne Weiteres helfen.

Wenn das mit max-linkspeed fluppt, dann mit jedem einzelnen Port der NIC. Wenn das auch jeweils fluppt, ist immerhin die Verbindung elektrisch sauber.

Und ja, testweise um die Sache einzugrenzen könntest Du auch mal eine Linux-LiveCD als Client ausprobieren - und wenn da SMB-Copy auch langsam ist, mal NFS testen. Dann bist Du auch schon einmal näher dran.

Ferner könntest Du auch mal die Systemauslastung in Augenschein nehmen - vielleicht wird ja zu viel Last auf der CPU erzeugt (Verschlüsselung, Kompression?) wenn die eine Kiste gleichzeitig senden und empfangen muss...

Schließlich könntest Du mal schauen, was passiert wenn zwei unterschiedliche Kisten vom einen Pool lesen und gleichzeitig auf den anderen Schreiben.

Und nicht zu vergessen: was ist'n das für ein Client? Windows? Linux?

Testweise mal sync writes abschalten (sudo zfs set sync=diabled pool/blablabla).

Abschließend:
Using file copy to measure storage performance – Why it’s not a good idea and what you should do instead
Copychunk - Service-side-copy unter Windows