[gelöst] mit NFS große Dateien kopieren sehr langsam

[debianfanboy]

Hallo Forum,
beim Kopieren großer Dateien mit NFS vom Client auf den Server bricht die Geschwindigkeit nach kurzer Zeit vollkommen zusammen. Kleine Dateien werden mit 40 MB/s kopiert, das ist bei Dateien über ca. 500 MB leider nur die ersten 10 Sekunden der Fall. Danach wird die Geschwindigkeit stetig langsamer und ist nach weiteren 10 Sekunden bei 20 MB/s und geht dann in nicht nennenswerte Raten über, so dass die große Datei praktisch nicht mehr kopiert werden kann.
Auf dem Server habe ich diese Zeile in /etc/exports:

Code: Alles auswählen

/mnt/share/video *CLIENT-IP*(rw,async,no_subtree_check,no_root_squash)

Auf dem Client habe ich diese Zeile in /etc/fstab:

Code: Alles auswählen

*SERVER-IP*:/mnt/share/video	/mnt/nfs/video	nfs     rw,async      0       0

Hat jemand 'ne Ahnung, worin die Ursache für diesen Performance-Einbruch liegen könnte?

Nachtrag: Wenn ich den Kopiervorgang dann abbreche, hängt sich alles massiv auf und es geht nicht mal mehr ein vernünftiger Shutdown...

[DeletedUserReAsG]

Hat jemand 'ne Ahnung, worin die Ursache für diesen Performance-Einbruch liegen könnte?

Du solltest noch Details, wie z.B. Art der Verbindung und involvierte Hardware, verraten. Klingt, als würde zunächst gecached werden.

[debianfanboy]

Ist das mit Art der Verbindung gemeint: 100-Mbit-Netzwerkkabel von Client zu Router (onboard-Netzwerkkarte I217-LM), genauso von Server zu Router. Der Server ist ein Raspberry Pi 2 B+ mit angeschlossener USB-Festplatte. Wie finde ich raus, ob da vorher was gecached wird? Das anstrengende ist leider, dass ein Ausprobieren im Totaleinfrieren endet. Der Prozess (nemo -n?) lässt sich nicht beenden und nichts geht mehr vernünftig. Jeder Versuch endet darin, dass ich reboot eingeben muss und es ewig dauert, bis da steht, dass alle filesystems umounted sind. Dann fährt er aber nicht wieder hoch und ich muss AUS/AN betätigen...

Nachtrag: inzwischen habe ich des Clients fstab mit den rsize=32768 und wsize=32768 Option ausgestattet und statt nfs nfs4 genommen, aber beide Versuche haben das gleiche Ergebnis erzeugt. Ärgerlich.

[DeletedUserReAsG]

Dann wird der Flaschenhals beim Pi liegen, sofern du nfs mit verschlüsselter Verbindung nutzt. Der kann nicht sonderlich viele MB/s entschlüsseln. Dein Client wird’s daher wegcachen bis Cache voll, und dann die Daten nur noch Häppchenweise kopieren. Ich denke, wenn du fünf bis zehn Minuten wartest (bei 500MB), wird auch dein System wieder benutzbar sein.

[TomL]

Der Server ist ein Raspberry Pi 2 B+ mit angeschlossener USB-Festplatte.

10 MB/s, maximal 12 MB/s sind das Limit... insofern ist bei Dir alles im grünen Bereich. Wenn Du GB-große Dateien kopieren willst, starte den Job im Hintergrund und kümmer Dich nicht mehr drum. Oder nutze einen Dateimanager, der Dir den Fortschritt anzeigt. Bei mir dauern 1,1 GB ca. 98 Sekunden, bei ~ 11 MB/s.

Der Grund ist der geshare'te Controller, der gleichzeitig Ethernet und USB macht.

[debianfanboy]

Das ist leider nach 5-10 Minuten nicht getan. Die Test-Datei ist 4,4 GB groß und ich habe schon 10 Minuten gewartet nachdem der Kopiervorgang bei 700 MB zum Erliegen gekommen ist. Nach dem Reboot war die Datei auf dem Server 800 MB groß. Nach Adam Riese heißt das ca. 170 kB/s und da warte ich auf die restliche Datei ca. zehn Stunden. So schlimm kann es doch nicht sein - trotz USB/eth-Flaschenhals. Eine Verschlüsselung nutze ich auch nicht.

Nachtrag: Wenn ich die gleiche Datei vom Server auf den Client kopiere, komme ich auf ca. 5,5 MB/s und der Kopiervorgang wird binnen 18 Minuten abgeschlossen. Andersherum genauso und ich wäre glücklich.

[DeletedUserReAsG]

Um zu überprüfen, ob’s an smb oder an den Umständen liegt: mit scp auf den Pi geht’s?

[debianfanboy]

Mit scp startet der Kopiervorgang bei etwa 2,2 MB/s und pegelt sich nach einigen Sekunden bei 300 KB/s ein.

Code: Alles auswählen

*FILM*.mkv                  3%   50MB 327.0KB/s 1:15:18 ETA

Also auch hier das gleiche Problem. Aber das Abbrechen des Vorgangs lässt sich ohne die oben genannten Probleme durchführen. Das ist schon mal gut. Es liegt wohl also an den Umständen? Runterkopieren vom Server auf den Client problemlos, vom Client auf den Server allerdings nur dürftig. Ich habe vorher smb genutzt, da ging das. Netzwerkkarte lässt sich also auch ausschließen. Das Problem scheint wohl woanders zu liegen?

[DeletedUserReAsG]

Das Pi muss in dem Fall die eingehenden Daten entschlüsseln und sich gleichzeitig um den USB-Controller kümmern, an dem Ethernet und deine Platte gleichermaßen hängen. Kann mir schon vorstellen, dass das problematisch ist – um Letzteres zu prüfen, mal das Gleiche machen, aber direkt nach /dev/null schreiben, so dass über den USB-Controller nur die Daten vom NIC gehen und das Wegschreiben nicht der Flaschenhals sein kann?

[debianfanboy]

Ok. Das scheint es zu sein.

Code: Alles auswählen

*FILM*.mkv                 15%  225MB   3.6MB/s   05:57 ETA

Beim Schreiben auf die SD-Karte tritt das Problem nicht auf. Danke für die Fehleranalyse! Eine Antwort zwei Folgefragen:

1. Warum passiert das nicht, wenn ich vom Server etwas hole?
2. Lässt sich das irgendwie konfigurieren, dass das nicht so derb ins Gewicht fällt? Ich wäre ja schon mit 2 MB/s zufrieden...

[DeletedUserReAsG]

Wenn du es holst, kann der Pi seinerseits Daten cachen und muss nicht für jeden Datenblock auf das Device zugreifen. Entsprechend würde ich dort ansetzen: gucken, ob sich nicht irgendwie ’n Cache für eingehende Daten definieren lässt, so dass es erstmal einige Daten sammeln, und dann mit einem Rutsch wegschreiben kann. Meine Kenntnisse bezüglich NFS und Co. halten sich aber stark in Grenzen, so dass ich da nicht weiterhelfen kann.

[debianfanboy]

Das ist schon mehr als genug. Danke für Deine Hilfe! Da ich nur selten so große Dateien auf den Server kopiere und aber auch NTFS auf den Platten beibehalten will, werde ich jetzt einfach zusätzlich einen 8GB-USB-Stick mit ext4 ranhängen und den quasi als Cache benutzen. Durch die Eingrenzung der Ursache konnte ich diesen Beitrag finden http://www.forum-raspberrypi.de/Thread- ... samba-wlan, welcher besagt, dass die Performance mit ext4 besser ist. Dann kopiere ich von dort weiter auf die NTFS-Festplatte. Berichte später über etwaige Erfolge und nenne das an der Stelle schon mal 'gelöst'.

[jph]

Unabhängig davon sollte man festhalten, dass ein Pi zu vielem zu gebrauchen ist. Er taugt aber nicht sonderlich als Fileserver.

[Colttt]

So nen Pi ist für sowas nicht auagelegt! Das sieht man daran das das Ethernet und die USB-Schnittstellen über EINEN USB Controller laufen.. Es gibt alternativen die SATA und 1Gbit interface bieten.. oder du kaufst dir ein microboard wo gleich nen Intel Atom drauf sitzt.

[debianfanboy]

Es läuft ja bei mir ein NAS mit Intel Atom, da funktioniert natürlich alles flüssiger. Der Pi am anderen Ende der Stadt ist nur als Backup-System zum Synchronisieren des eigentlichen NAS gedacht und liefert aber gleichtzeitig über NFS ziemlich erfolgreich die Medien an einen weiteren Raspberry mit OSMC drauf. Außerdem eignet er sich auch ziemlich gut als eBook-Server. Konnte da bisher nicht meckern.

[scientific]

Übrigens danke für diesen Thread. Ich liebäugle schon länger mit ein PI als Backupserver... Jetzt nicht mehr. [emoji4]

Welche Alternativen in dieser Preisklasse gäbs da?

(Asche auf mein Haupt -> neuer eigener Thread...)

Lg scientific

[DeletedUserReAsG]

In dieser Preisklasse? Nix. Zwei oder drei Zehner mehr, und man könnte ’nen Cubitruck nehmen. Hat SATA und GBit/s-Ethernet onboard und ist diesbezüglich recht brauchbar.

[TomL]

Übrigens danke für diesen Thread. Ich liebäugle schon länger mit ein PI als Backupserver... Jetzt nicht mehr.

Nur mal so aus Neugier... hast Du mal die Datenmengen ermittelt, die effektiv automatisch durch Backups im Jahresdurchschnitt täglich bewegt werden müssen? Eigentlich ist das doch die einzige Größe, die festlegt, welche Leistungsklasse ein reiner Backup-Server haben muss. Bei uns sind das von der 3 TB-Arbeitsplatte zur zweiten HD nur ein paar MB tatsächliche Änderungen, machmal etwas mehr, meistens aber nicht. Und der tägliche Sync von der Server-SSD ebenfalls zur zweiten HD ist auch kaum nennenswert. Das gesamte Backupgeschäft beschäftigt unseren PI jeden Monat (bei ca. 240 Nachtstunden ungenutzter Zeit, also außerhalb des User-Fensters) allerhöchstens 4-6 Stunden im gesamten Monat. Welche sinnvolle Verbesserung ist da mit mehr Power zu erwarten?

Die Angaben aus diesem Thread finde ich persönlich jetzt ein wenig ungeeignet zur Bewertung als privater Backupserver. Gerade auch vor dem Aspekt des Stromverbrauchs und der angekündigten Preis-Entwicklung bei einem 7/24 Betrieb aufs Jahr hochgerechnet. Anders wäre es, wenn es einen geschäftlichen Background mit vertraglich zugesagten Verfügbarkeits-Garantien und festen Reaktionszeiten hätte. Dann würde ich den PI auch nicht als allererste Wahl betrachten.

j.m.2.c.

[Lord_Carlos]

Welche Alternativen in dieser Preisklasse gäbs da?

Etwas teurer, aber vielleicht ein BananaPi?
Ich meine die gibt es auch mit hardware AES Beschleunigung.

[scientific]

Nun ja... Ich hörte/las schon so einiges über den Flaschenhals beim RPi...

Es sind natürlich über das Jahr gerechnet geringe Mengen. Aber bei mir kommen doch alle paar Tage viele MB an Videomaterial hinzu, da ich viel filme.
Wenn ich dann übers Netz sichere, soll der Vorgang dann nicht ewig blockieren, sondern zügig durchlaufen.
Derzeit mach ich es per USB-Platte, später dann auf den Server, wovon eine Strecke per WLAN läuft.

Und nichts ist lästiger als man will den Rechner ausschalten und das hängt, weil der Netzwermount das Filesystem blockiert...

Lg scientific

[Lord_Carlos]

Ich wollte ueber die naechsten Wochen auch ein rPi als offsite backup benutzten.
Ich meine gelesen zu haben das er doch so 8 - 10MB/s schaffen sollte. Wenn jetzt nichts mit verschluesselung hinzukommt. Naja, werde ich dann mal sehen.

[jph]

Das gesamte Backupgeschäft beschäftigt unseren PI jeden Monat (bei ca. 240 Nachtstunden ungenutzter Zeit, also außerhalb des User-Fensters) allerhöchstens 4-6 Stunden im gesamten Monat. Welche sinnvolle Verbesserung ist da mit mehr Power zu erwarten?

Wenn die Backup-Quelle 24x7 aktiv ist und sozusagen alle Zeit der Welt für ihr Backup zur Verfügung hat, mag deine Argumentation zutreffen. Bei einem Laptop oder einem Desktop-Rechner, der abends mal ein, zwei Stündchen läuft, sieht das schon anders aus. Da muss das Backup innerhalb dieses Zeitfensters abgeschlossen werden. Was dann zu oft nicht klappt und das Backup unsicher macht. BTDT.

[TomL]

Ich wollte ueber die naechsten Wochen auch ein rPi als offsite backup benutzten.
Ich meine gelesen zu haben das er doch so 8 - 10MB/s schaffen sollte. Wenn jetzt nichts mit verschluesselung hinzukommt. Naja, werde ich dann mal sehen.

Beim gerade durchgeführten Test mit einer 5-GB-Datei (5127 MB) vom Server (RPI) runter auf meinen Rechner ist die effektive Übertragung 11,22 MB/s. Die gleiche Datei umbenannt von meinen Rechner zurück auf den Server wird mit 10,4 MB/s übertragen. Da solche Dateien aber nur seltene ungewöhnliche Spitzen im normalen Tagesgeschäft darstellen, ist diese Zeit für mich absolut sekundär in ihrer Bedeutung. Wenn ich weiss, dass so eine Datei 7-8 Minuten oder vielleicht sogar länger dauert, dann starte ich das nicht, wenn ich gleich was anderes vorhabe, sondern lass es laufen, wenn ich TV gucke und eh nix anderes zu tun habe. Und mal ehrlich, normale Multimedia-Dateien verschlüsseln... ?... das halte ich wahrlich für unnötig. Mein PI ist ein einfacher Samba-Server.

[TomL]

Bei einem Laptop oder einem Desktop-Rechner, der abends mal ein, zwei Stündchen läuft, sieht das schon anders aus. Da muss das Backup innerhalb dieses Zeitfensters abgeschlossen werden. Was dann zu oft nicht klappt und das Backup unsicher macht. BTDT.

Genau das war das Problem... eines, mit dem ich bei 10-15 Clients schlichtweg überfordert war. Aus dem Grund werden die Geräte heute gar nicht mehr gesichert, sondern verwenden entweder direkt den Server oder syncen sich kontinuierlich dorthin. Ist also alles eine Frage der Organisation.

[scientific]

Nun...
In meinem Setup werden mit btrfs auch nur die Teile gesynced, die sich geändert haben. Und das stündlich.

Kommt jetzt ein Film mit 2 GB daher, ist die Datenmenge 2 GB+irgendwelche Metainfos, die dann sofort gesichert werden (müssen).
Ob ich jetzt mit rsync, mit btrfs send/receive odee smb oder nfs mit dem Server die Daten austausche, bleibt wohl ziemlich einerlei, wenn der Server einen Flaschenhals wie der Raspi hat. 2GB sind 2 GB, die jetzt im Moment übers Netz an den Server geschickt und dort verarbeitet werden müssen.

Bei einem Backup mit rsync oder btrfs kann ich immer noch entscheiden, wann genau ich es schicken will (wenn es nicht automatisch gemacht wird). Bei smb oder nfs-mount von HOME passiert es in der Sekunde des Speicherns.

Oder hab ich da was falsch verstanden?