Linux Geschwindigkeit Datenübertragung

[Guxtu]

Kollegen, hier gibt es eine Sache, die ich nicht verstehe.
Vielleicht kann mir jemand einen Tipp geben.

Beteiligte
Fritzbox 7560
TP T420 unter LMDE 6 mit SSD
TP T480 unter LMDE 6 mit SSD
Ich

Umstände
Beide TP im WLAN-Heimnetz. WLAN-Verbindung 5GHz AC, per Fritzbox angezeigte Geschwindigkeit für Upload/Download >500MBit/s. 5 Geräte an der FB angemeldet und ohne Netzlast bis auf die beteiligten beiden. Keinen interferierenden WLAN-Netze.
Das Filesystem des T420 ist per NFS im T480 eingehängt.
Ich kopiere per Drag and Drop einen Dateibaum mit ca. 10.000 Dateien und 3 GB Größe vom T480 auf das T420.

Problem
Die erreichte Kopiergeschwindigkeit beträgt ca 2MB/s=16MBit/s. Das ist noch nicht mal 10% der theoretisch möglichen Geschwindigkeit und mMn nicht durch Overhead erklärbar.
Wenn ich dann auf dem T420 den Dateibaum auf eine HDD im Caddy kopiere, erreiche ich ca 40MB/s.
Auf beiden TPs erreiche ich im Download aus dem Internet locker die spezifizierten 100Mbit/s.
Ich sehe das Problem also weder im Dateibaum noch in der WLAN-Verbindung.

Woran liegt die niedrige Kopiergeschwindigkeit? Kann ich das ändern?

Danke im Vorab für Hinweise.

 

[elchmartin]

Als nicht-Poweruser sondern Lernender im Bereich Linux:
Was passiert, wenn Du die Freigabe per SMB/CIFS erstellst und die Daten kopierst?
Oder, sicherlich Overkill, per iSCSI... Hab ich aber letztens für eine spezielle Konstellation entdeckt.

Aus der Praxis: bei FTP zB sind kleine Dateien auch mega ineffizient. SMB wesentlich schneller.

 

[Gummiente]

Mir fällt es schwer zu glauben, dass irgendeine halbwegs relevante Switchhardware heutzutage Schwierigkeiten bekommen sollte alle Ports mit voller Geschwindigkeit zu bedienen. Selbst ein 20 EUR 4 Port Switch schaltet wahrscheinlich 4 GBIT/s durch.

Das Problem mit kleinen Dateien sehe ich immer beim Entpacken von riesigen Treiberpaketen bei Windows. Auf einem PCIE 4 M.2 SSD die mühelos über 4.000 MB/s erreichen sackt die Rate auf niedrige einstellige MB/s ab, wahrscheinlich wenn es an die vielen kleineren Dateien geht. Komisch, denn die astronomisch hohen IOPS Angaben wecken Erwartungen.

Alles ohne Gewähr da anekdotenhafte Beobachtungen.

 

[Ravensberger]

Moin,
lt. diesem Beitrag ist unverschlüsseltes NFS, wovon ich hier einmal ausgehe, gar nicht langsam:

NAS Performance: NFS vs. SMB vs. SSHFS

This is a performance comparison of the the three most useful protocols for networks file shares on Linux with the latest software. I have run sequential and random benchmarks and tests with rsync. The main reason for this post is that i could not find a proper test that includes SSHFS.

blog.ja-ke.tech

 

[Korfox]

Moin,
lt. diesem Beitrag ist unverschlüsseltes NFS, wovon ich hier einmal ausgehe, gar nicht langsam:

NAS Performance: NFS vs. SMB vs. SSHFS

This is a performance comparison of the the three most useful protocols for networks file shares on Linux with the latest software. I have run sequential and random benchmarks and tests with rsync. The main reason for this post is that i could not find a proper test that includes SSHFS.

blog.ja-ke.tech

rw,async,all_squash,anonuid=1000,anongid=1000

Hervorhebung von mir.
Der Sync kostet sehr viel. Das selbe auch, wenn man z.B. ZFS synced einhängt (da ist der Impact afaik nicht ganz so relevant).
Ansonsten gilt im Endeffekt halt für alle gängigen Möglichkeiten über Netzwerk auf Dateisysteme zuzugreifen:
Die benutzen (fast) ausschließlich TCP. Und damit ist die Bandbreite durch den Overhead einfach massiv reduziert - vor allem bei vielen kleinen Dateien. Man könnte die Paketgrößen von NFS (rsize und wsize) noch erhöhen, aber auch hier ist der Einfluss eher gering.

Am meisten dürfte NFS von async und der erwähnte Netcat-Tarpipe bringen. Damit käme man auch verschlüsselt zumindest (knapp) auf den Durchsatz von SMB .

Zum Overhead von TCP noch:

Hello, would you like to hear a TCP joke?
Yes, I'd like to hear a TCP joke.
OK, I'll tell you a TCP joke.
OK, I'll hear a TCP joke.
Are you ready to hear a TCP joke?
Yes, I am ready to hear a TCP joke.
OK, I'm about to send the TCP joke. It will last 10 seconds, it has two characters, it does not have a setting, it ends with punchline.
OK, I'm ready to hear the TCP joke that will last 10 seconds, has two characters, does not have a setting and will end with a punchline.
I'm sorry, your connection has timed out... ...Hello, would you like to hear a TCP joke?

Und warum man dann nicht auf UDP setzt?
Naja...

I would like to tell you a UDP joke. But you may not get it. And I don't care.

 

[rrbs]

"Das Filesystem des T420 ist per NFS im T480 eingehängt." wie ist es denn eingehaengt?

 

[Korfox]

1. Wie != Als was, sondern mit welchen Parametern
2. Wie ist es im T420 eingehängt und was für ein Dateisystem ist es?

 

[Guxtu]

Severseitig (T420) in der /etc/exports:
/home/username/Backup_1 192.168.178.60(rw,no_subtree_check)

Clientseitig (T480):
sudo mount -t nfs 192.168.178.37:/home/username/Backup_1 /mnt/Backup_1

Keine Verschlüsselung.
Dateisystem ist Standard, wie es von LMDE eben angelegt wird.

 

[Korfox]

Clientseitig würde ich dann Mal folgendes testen:
sudo mount -o async -t nfs 192.168.178.37:/home/username/Backup_1 /mnt/Backup_1

(Natürlich mit dem Hinweis, dass es dann zu Datenverlust kommen kann, wenn der Server crashed bevor die Daten alle geschrieben sind...)
Serverseitig wird es dann ext4 sein... iirc sollte das per default lokal async eingebunden werden.

 

[Guxtu]

Eben probiert (Danke ans Homeoffice):
exportieren mit /home/username/Backup_1 192.168.178.60(rw,async, no_subtree_check)

Und siehe da: Geschwindigkeit steigt von 3MB/s auf 8MB/s im Schnitt, bei großen Dateien auf >40MB/s.
Mount mit async probiere ich noch.

Damit macht das Ganze wieder Sinn.

Vielen Dank an die vielen Hinweisgeber.

Nebenbei: Linux-Ecke war doch richtig.

 

[Mornsgrans]

Ich sehe bislang keine Logik daran, dass es sich um ein Linux- Thema handeln muss.

Hat hier jemand "Jehova" gesagt?

 

[Ravensberger]

Hat hier jemand "Jehova" gesagt?

Auf den Poden mit dem Purschen!

Mit meiner Fritte habe ich einiges erlebt, das ich gerne verstehen würde. Ich mag sie trotzdem, aber folgender Satz von @Mr. Natural bringt es meines Erachtens gut auf den Punkt:

Ich hab kürzlich erst mein UniFi Gateway direkt an die Glasfaser gehängt und die 7530 zu einem nachgelagerten reinen IP-Client degradiert, der nur noch Telefon macht. Das machen die Fritzen ja echt gut...

Wenn sich internes Netzwerk auch über Fritz! Produkte gut abbilden ließen, würde mein Lieblingsarbeitgeber bestimmt nicht den achtfachen Preis für Cisco Access Points ausgeben. Telefonie für zuhause macht die Fritte dagegen schon fast perfekt.

 

[Korfox]

Eben probiert (Danke ans Homeoffice):
exportieren mit /home/username/Backup_1 192.168.178.60(rw,async, no_subtree_check)

Und siehe da: Geschwindigkeit steigt von 3MB/s auf 8MB/s im Schnitt, bei großen Dateien auf >40MB/s.
Mount mit async probiere ich noch.

Das ist irritierend, weil Ext4 eigentlich, wie gesagt, eh asynchron eingehängt sein sollte und nicht für jeden Schreibvorgang auf eine Bestätigung wartet . Wieder etwas gelernt.
Bleibt aber dabei, dass Transferraten allgemein mit kleinen Dateigrößen und NFS im speziellen mit der Sync sterben.

 

[Guxtu]

Im Gegenzug bringt zusätzliches mounten mit async keinen weiteren Geschwindigkeitszuwuchs.
Allerdings alles nur mit schreibendem Client getestet, nicht lesen.
Und ja, kleine Dateien sind des Teufels, hier wohl ganz besonders.

Nun ja.

Jetzt kann ich mir überlegen, ob ich rsync (kopiere nur was neu ist) einsetze oder tar (kopiere alles als ein File).
Das ist Doing und kein Understanding.