Langsames Kopieren zwischen NFS/CIFS-Verzeichnissen auf demselben Server

Question

Hmm ... mir sind tatsächlich ein paar Probleme aufgefallen und ich glaube, ich habe ein oder zwei stichhaltige Beweise gefunden. Aber zuerst werde ich ein paar Fragen stellen und Annahmen über Ihre wahrscheinlichen Antworten treffen. Ich werde einige Daten präsentieren, die zunächst irrelevant erscheinen, aber ich verspreche, dass es sich lohnt, sie zu lesen. Also, bitte, warten Sie darauf ... :-)

Ich gehe davon aus, dass Sie bei RAID 10 insgesamt vier Laufwerke im Stripe-Format und redundant haben.
Und dass Sie Linux Autoraid verwenden (im Gegensatz zu einem Hardware-RAID-Controller).
Ich gehe außerdem davon aus, dass alle SATA-Ports unabhängig voneinander mit voller Übertragungsgeschwindigkeit bidirektional übertragen können und dass alle SATA-Ports gleich schnell sind. Das heißt, wenn Sie einen einzelnen SATA-Adapter/Controller haben, ist dieser in der Lage, alle daran angeschlossenen Festplatten mit Nenngeschwindigkeit zu betreiben.
Ich gehe auch davon aus, dass Sie die neuesten SATA-Laufwerke + Controller haben. Das sind 6,0 Gb/s. Das sind 600 MB/s. Um konservativ zu sein, nehmen wir an, dass wir die Hälfte davon bekommen, also 300 MB/s
Die Verbindung vom Client zum Server ist durch die Netzwerkkarte begrenzt (auf 100 MB/s), sodass die Laufwerke nicht ausreichend beansprucht werden können.
Um bei NFS-zu-NFS schneller als die Netzwerkkarte zu sein, gehe ich davon aus, dass Sie localhost verwenden, sodass Sie die durch die Netzwerkkarte begrenzten Geschwindigkeiten überschreiten können (ich glaube, Sie sagten, Sie hätten Bonding verwendet, um zu zeigen, dass dies kein Problem ist).

PROBLEM Nr. 1. Ihre gemeldeten Übertragungsraten selbst für schnelle lokale Verbindungen scheinen niedrig zu sein. Bei so schnellen Festplatten würde ich mehr als 150 MB/s erwarten. Ich habe ein 3-Festplatten-RAID0-System, das nur 3,0 Gb/s schafft [Adapter begrenzt], und ich kann 450 MB/s im Stripe-Verfahren erreichen. Ihre Festplatten/Controller sind doppelt so schnell wie meine, daher würde ich [aufgrund des Stripe-Verfahrens] erwarten, dass Sie 300 MB/s und nicht nur 150 MB/s im lokalen Verfahren erreichen. Oder vielleicht sogar 600 MB/s [abzüglich FS-Overhead, der es der Diskussion halbieren könnte].

Aus Ihren Zpool-Informationen habe ich erkannt, dass es sich bei Ihrer Festplattenkonfiguration um Western Digital handelt und zwar:

Spiegel-0
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0
Spiegel 1
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0

Vergleichen wir dies nun mit Ihren Iostat-Informationen. Es wäre zwar schön, für alle Tests Iostat-Informationen über alle Laufwerke zu haben, aber ich glaube, ich kann das Problem allein mit dem diagnostizieren, was Sie bereitgestellt haben.
SDB und SDD sind ausgelastet
Wie Sie bemerkt haben, ist diesseltsam. Ich würde erwartenalleLaufwerke, die in einem Raid10 eine ausgeglichene Nutzung/Statistik aufweisen. Das ist [mein] eindeutiger Beweis.
Die beiden kombinieren. Die voll ausgelasteten Laufwerke sind ein etwas anderes Modell als die, die es nicht sind. Ich gehe davon aus, dass die Zpool-Reihenfolge sda/sdb sdc/sdd ist [aber sie könnte umgekehrt sein].
sda/sdc sind 68AX9N0
sdb/sdd sind 68EUZN0

PROBLEM Nr. 2. Bei einer Google-Suche nach WD20EFRX + 68AX9N0 + 68EUZN0 habe ich diese Seite gefunden:http://forums.whirlpool.net.au/archive/2197640

Es scheint, dass die 68EUZN0-Laufwerke ihren Kopf nach etwa 8 Sekunden parken können, während das andere diesbezüglich schlauer ist [oder umgekehrt].

Wenn also NFS-Caching + FS-Caching + SSD-Caching vorhanden sind, können die zugrunde liegenden Laufwerke inaktiv werden und ihre Köpfe parken. Ich vermute, dass die zusätzliche Caching-Ebene von NFS der Grund für den Überschuss ist.

Sie können dies testen, indem Sie die FS-Synchronisierungsoptionen variieren. Vielleicht ist Synchronisierung besser als Asynchronität. Wenn möglich, würde ich die Tests auch mit deaktiviertem SSD-Caching wiederholen. Die Idee ist, sicherzustellen, dass das Parkennichtauftreten und die Ergebnisse sehen.

Wie auf der Webseite erwähnt, gibt es einige Dienstprogramme, mit denen sich das Parkverzögerungsintervall anpassen lässt. Wenn dies die Option ist, informieren Sie sich gründlich darüber.

AKTUALISIEREN:

Ihr Problem kann als Durchsatzproblem durch ein Store-and-Forward-Netzwerk [mit garantierter Zustellung] betrachtet werden. Beachten Sie, dass ichnichtwir sprechen über die Netzwerkkarte oder ein gleichwertiges Gerät.

Bedenken Sie, dass ein E/A-Vorgang wie ein Paket ist, das eine Anforderung enthält (z. B. Lesen/Schreiben, Pufferadresse, Pufferlänge), die in einer Struktur gespeichert wird. Dieses Anforderungspaket/diese Struktur wird zwischen den verschiedenen Cache-Ebenen weitergegeben: NFS, ZFS, Gerätetreiber, SATA-Controller, Festplatte. An jedem Punkt haben Sie eine Ankunftszeit auf der Ebene und eine Abfahrtszeit, wenn die Anforderung an die nächste Ebene weitergeleitet wird.

In diesem Zusammenhang ist die tatsächliche Festplattenübertragungsgeschwindigkeit, wenn die Übertragung tatsächlich stattfindet, analog zur Verbindungsgeschwindigkeit. Wenn die meisten Leute an Festplatten denken, berücksichtigen sie nur die Übertragungsgeschwindigkeit und nicht, wann die Übertragung tatsächlich eingeleitet wurde.

In einem Netzwerkrouter kommen Pakete an, werden aber nicht immer sofort weitergeleitet, selbst wenn die ausgehende Verbindung frei ist. Je nach Routerrichtlinie kann der Router das Paket etwas verzögern, in der Hoffnung, dass noch weitere Pakete aus anderen Quellen [oder aus derselben Quelle bei UDP] eintreffen, damit der Router die kleineren Pakete zu einem großen Paket zusammenfassen kann, das effizienter über die ausgehende Verbindung übertragen werden kann.

Bei Festplatten könnte diese „Verzögerung“ durch die Cache-Richtlinie einer bestimmten FS-Schicht charakterisiert werden. Mit anderen Worten: Wenn eine Anfrage zur Zeit T bei einer Schicht ankommt, könnte sie die Schicht nicht bei T+1 verlassen und bei T+1 bei der nächsten Schicht ankommen, sondern bei T+n. Eine FS-Cache-Schicht könnte dies tun, damit sie eine Suchreihenfolgeoptimierung/-sortierung durchführen kann.

Das Verhalten, das Sie beobachten, ist einem TCP-Socket sehr ähnlich, der sein Fenster aufgrund einer Überlastung reduziert hat.

Ich denke, es ist wichtig, die Tests aufzuteilen. Im Moment führen Sie Lese- und Schreibvorgänge durch. Und Sie wissen nicht, was der limitierende Faktor/Engpass ist. Ich denke, es wäre hilfreich, die Tests in Lese- und Schreibvorgänge aufzuteilen. Ein ordentliches Benchmark-Programm wird das wahrscheinlich tun. Was ich befürworte, ist eine ausgefeiltere Version von [das sind nur grobe Beispiele, nicht die genauen zu verwendenden Argumente]:

Für das Schreiben, Zeit dd if=/dev/zero of=/whatever_file count=64g
Zum Lesen, Zeit dd wenn=/was auch immer von=/dev/null Anzahl=64g

Der Grund für 64 GB ist, dass das das Doppelte Ihres physischen RAM ist und Block-Cache-Effekte eliminiert. Führen Sie den Synchronisierungsbefehl zwischen den Tests aus.

Wenden Sie dies auf dem lokalen FS an und wiederholen Sie es auf NFS.

Machen Sie auch dielesenTesten Sie jeweils /dev/{sda,sdb,sdc,sdd}

Führen Sie während dieser Tests Iostat durch.

Beachten Sie, dass der Lesetest auf der physischen Rohdiskette Ihnen einen Basiswert/ein Maximum dafür liefert, wie schnell die Hardware tatsächlich sein kann. Die Rohgeräte-Lesevorgänge sollten ungefähr den maximalen Übertragungskapazitäten Ihrer Laufwerke entsprechen. Die erwartete Schreibgeschwindigkeit sollte für eine Festplatte ähnlich sein. Wenn nicht, warum nicht? Alle Disketten sollten ungefähr die gleiche Geschwindigkeit aufweisen. Was ich hier herausfinden möchte, ist der Grund, warum in Ihren vorherigen Tests nur zwei Disketten maximal ausgelastet sind.

Wenn man nachrechnet, dass es bei 32 GB und einer angenommenen maximalen Übertragungsgeschwindigkeit von 600 MB/s mindestens 50 Sekunden dauern würde, um das zu füllen/leeren. Wie hoch ist also das Park-Timeout eingestellt?

Sie können die Dinge auch ein wenig variieren, indem Sie die Menge an physischem RAM reduzieren, die der Kernel über den Boot-Parameter mem= zulässt. Versuchen Sie es mit etwas wie mem=8g, um zu sehen, welche Wirkung es hat. Es gibt auch einige /proc-Einträge, die die Block-Layer-Cache-Flush-Richtlinie anpassen können.

Außerdem sind meine FSes ext4 und mit noatime gemountet. Vielleicht möchten Sie Folgendes in Betracht ziehenzfs set atime=off ...

Beobachten Sie auch das Systemprotokoll. Manchmal meldet ein Laufwerk einen Fehler und das System konfiguriert es neu, um eine niedrigere Übertragungsgeschwindigkeit zu verwenden.

Sehen Sie sich auch die SMART-Daten für die Laufwerke an. Fällt Ihnen etwas Ungewöhnliches auf? Zu viele Soft-Retries auf einem bestimmten Laufwerk (z. B.).

Wie ich bereits sagte, ist die Leistung der lokalen Festplatte viel geringer als erwartet. Ich denke, dieses Problem muss zuerst gelöst werden, bevor man das gesamte System mit NFS in Angriff nimmt. Wenn alle RAID-Festplatten eine ausgewogene Auslastung hätten und im Rahmen lägen, wäre ich weniger besorgt.

Mein System [das auch WDC-Festplatten hat] ist nicht für NFS konfiguriert (ich verwende rsync häufig). Ich muss in den nächsten 1-2 Tagen dringende Dinge erledigen. Danach habe ich Zeit, es auszuprobieren [ich wäre selbst neugierig].

UPDATE #2:

Guter Hinweis auf das Problem des ZFS-Ungleichgewichts. Dies hilft, mein „Problem Nr. 1“ zu erklären. EskönnteErklären Sie auch die Unzuverlässigkeit von NFS, wenn die Neuausgleichsvorgänge NFS hinsichtlich Latenz/Timing irgendwie verwirrten und das „TCP-Fenster/Backoff“-Verhalten verursachten – keine sehr hohe Wahrscheinlichkeit, aber dennoch eine Möglichkeit.

Beim Testen von rsync ist es nicht notwendig/willens, NFS zu verwenden. Wenn Sie per SSH auf den Server zugreifen können, rsyncUndNFS ist redundant. Verwenden Sie bei NFS einfach cp usw. Um rsync auszuführen, gehen Sie per SSH direkt zum zugrunde liegenden ZFS. Dies funktioniert auch ohne NFS-Mount [hier ist die von mir verwendete rsync-Konfiguration]:

exportiere RSYNC_SSH="/usr/bin/ssh"
exportiere SSH_NOCOMPRESS=1
rsync /wherever1 server:/zfsmount/was auch immer

Wenn Sie dies localhost oder bonded tun, kann die Leistung Ihren Erwartungen entsprechen (ohne das ZFS-Ungleichgewichtsproblem). Wenn dies der Fall ist, wird das Problem eindeutig auf NFS eingegrenzt.selbst.

Ich habe mir einige Kernel-Quellcodes für NFS angesehen. Was ich gesehen habe, gefiel mir hinsichtlich der Aktualität nicht. NFS wurde in den 80er Jahren eingeführt, als die Verbindungen noch langsam waren. Daher enthält es [immer noch] viel Code, um die NIC-Bandbreite zu schonen. Das heißt, eine Aktion wird nur dann „festgeschrieben“, wenn es unbedingt nötig ist. Das ist nicht unbedingt das, was wir wollen. In meiner phantasievollen Analogie zur Netzwerkrouter-Richtlinie scheint der Cache von NFS derjenige mit der „T+n“-Verzögerung zu sein.

Ich würde empfehlen, alles zu tun, um den Cache von NFS zu deaktivieren und seine Anfrage so schnell wie möglich an ZFS weiterzuleiten. Lassen Sie ZFS das intelligente Cache-Modul sein und NFS die „dumme Leitung“. NFS-Caching kann nur allgemeiner Natur sein (z. B. weiß es nicht einmal, dass der Sicherungsspeicher ein RAID ist, oder weiß nicht zu viel über die besonderen Eigenschaften des Basis-FS, auf dem es gemountet ist). ZFS verfügt über umfassende Kenntnisse des RAID und der Festplatten, aus denen es besteht. Daher kann der Cache von ZFS bei der Auswahl viel intelligenter sein.

Ich würde sagen, versuchen Sie, NFS dazu zu bringen, eine Synchronisierungsmontage durchzuführen – das könnte funktionieren. Außerdem habe ich etwas über noatime gesehen, also aktivieren Sie diese Option ebenfalls. Möglicherweise gibt es noch andere NFS-Tuning-/Montageoptionen. Wenn NFS der übliche Verdächtige ist, kann es hoffentlich neu konfiguriert werden, damit es gut genug funktioniert.

Wenn andererseits keine Option NFS in den Griff bekommt, wäre dann rsync über ssh eine brauchbare Alternative? Was ist der eigentliche Anwendungsfall? Es scheint, dass Sie NFS als Kanal für große Massenübertragungen verwenden, die eine hohe Leistung erfordern (im Gegensatz zu [sagen wir] nur als Automount-Punkt für Benutzer-Home-Verzeichnisse). Ist dies für Dinge wie Client-Backups auf Server usw. gedacht?

Answer 1

Hmm ... mir sind tatsächlich ein paar Probleme aufgefallen und ich glaube, ich habe ein oder zwei stichhaltige Beweise gefunden. Aber zuerst werde ich ein paar Fragen stellen und Annahmen über Ihre wahrscheinlichen Antworten treffen. Ich werde einige Daten präsentieren, die zunächst irrelevant erscheinen, aber ich verspreche, dass es sich lohnt, sie zu lesen. Also, bitte, warten Sie darauf ... :-)

Ich gehe davon aus, dass Sie bei RAID 10 insgesamt vier Laufwerke im Stripe-Format und redundant haben.
Und dass Sie Linux Autoraid verwenden (im Gegensatz zu einem Hardware-RAID-Controller).
Ich gehe außerdem davon aus, dass alle SATA-Ports unabhängig voneinander mit voller Übertragungsgeschwindigkeit bidirektional übertragen können und dass alle SATA-Ports gleich schnell sind. Das heißt, wenn Sie einen einzelnen SATA-Adapter/Controller haben, ist dieser in der Lage, alle daran angeschlossenen Festplatten mit Nenngeschwindigkeit zu betreiben.
Ich gehe auch davon aus, dass Sie die neuesten SATA-Laufwerke + Controller haben. Das sind 6,0 Gb/s. Das sind 600 MB/s. Um konservativ zu sein, nehmen wir an, dass wir die Hälfte davon bekommen, also 300 MB/s
Die Verbindung vom Client zum Server ist durch die Netzwerkkarte begrenzt (auf 100 MB/s), sodass die Laufwerke nicht ausreichend beansprucht werden können.
Um bei NFS-zu-NFS schneller als die Netzwerkkarte zu sein, gehe ich davon aus, dass Sie localhost verwenden, sodass Sie die durch die Netzwerkkarte begrenzten Geschwindigkeiten überschreiten können (ich glaube, Sie sagten, Sie hätten Bonding verwendet, um zu zeigen, dass dies kein Problem ist).

PROBLEM Nr. 1. Ihre gemeldeten Übertragungsraten selbst für schnelle lokale Verbindungen scheinen niedrig zu sein. Bei so schnellen Festplatten würde ich mehr als 150 MB/s erwarten. Ich habe ein 3-Festplatten-RAID0-System, das nur 3,0 Gb/s schafft [Adapter begrenzt], und ich kann 450 MB/s im Stripe-Verfahren erreichen. Ihre Festplatten/Controller sind doppelt so schnell wie meine, daher würde ich [aufgrund des Stripe-Verfahrens] erwarten, dass Sie 300 MB/s und nicht nur 150 MB/s im lokalen Verfahren erreichen. Oder vielleicht sogar 600 MB/s [abzüglich FS-Overhead, der es der Diskussion halbieren könnte].

Aus Ihren Zpool-Informationen habe ich erkannt, dass es sich bei Ihrer Festplattenkonfiguration um Western Digital handelt und zwar:

Spiegel-0
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0
Spiegel 1
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0

Vergleichen wir dies nun mit Ihren Iostat-Informationen. Es wäre zwar schön, für alle Tests Iostat-Informationen über alle Laufwerke zu haben, aber ich glaube, ich kann das Problem allein mit dem diagnostizieren, was Sie bereitgestellt haben.
SDB und SDD sind ausgelastet
Wie Sie bemerkt haben, ist diesseltsam. Ich würde erwartenalleLaufwerke, die in einem Raid10 eine ausgeglichene Nutzung/Statistik aufweisen. Das ist [mein] eindeutiger Beweis.
Die beiden kombinieren. Die voll ausgelasteten Laufwerke sind ein etwas anderes Modell als die, die es nicht sind. Ich gehe davon aus, dass die Zpool-Reihenfolge sda/sdb sdc/sdd ist [aber sie könnte umgekehrt sein].
sda/sdc sind 68AX9N0
sdb/sdd sind 68EUZN0

PROBLEM Nr. 2. Bei einer Google-Suche nach WD20EFRX + 68AX9N0 + 68EUZN0 habe ich diese Seite gefunden:http://forums.whirlpool.net.au/archive/2197640

Es scheint, dass die 68EUZN0-Laufwerke ihren Kopf nach etwa 8 Sekunden parken können, während das andere diesbezüglich schlauer ist [oder umgekehrt].

Wenn also NFS-Caching + FS-Caching + SSD-Caching vorhanden sind, können die zugrunde liegenden Laufwerke inaktiv werden und ihre Köpfe parken. Ich vermute, dass die zusätzliche Caching-Ebene von NFS der Grund für den Überschuss ist.

Sie können dies testen, indem Sie die FS-Synchronisierungsoptionen variieren. Vielleicht ist Synchronisierung besser als Asynchronität. Wenn möglich, würde ich die Tests auch mit deaktiviertem SSD-Caching wiederholen. Die Idee ist, sicherzustellen, dass das Parkennichtauftreten und die Ergebnisse sehen.

Wie auf der Webseite erwähnt, gibt es einige Dienstprogramme, mit denen sich das Parkverzögerungsintervall anpassen lässt. Wenn dies die Option ist, informieren Sie sich gründlich darüber.

AKTUALISIEREN:

Ihr Problem kann als Durchsatzproblem durch ein Store-and-Forward-Netzwerk [mit garantierter Zustellung] betrachtet werden. Beachten Sie, dass ichnichtwir sprechen über die Netzwerkkarte oder ein gleichwertiges Gerät.

Bedenken Sie, dass ein E/A-Vorgang wie ein Paket ist, das eine Anforderung enthält (z. B. Lesen/Schreiben, Pufferadresse, Pufferlänge), die in einer Struktur gespeichert wird. Dieses Anforderungspaket/diese Struktur wird zwischen den verschiedenen Cache-Ebenen weitergegeben: NFS, ZFS, Gerätetreiber, SATA-Controller, Festplatte. An jedem Punkt haben Sie eine Ankunftszeit auf der Ebene und eine Abfahrtszeit, wenn die Anforderung an die nächste Ebene weitergeleitet wird.

In diesem Zusammenhang ist die tatsächliche Festplattenübertragungsgeschwindigkeit, wenn die Übertragung tatsächlich stattfindet, analog zur Verbindungsgeschwindigkeit. Wenn die meisten Leute an Festplatten denken, berücksichtigen sie nur die Übertragungsgeschwindigkeit und nicht, wann die Übertragung tatsächlich eingeleitet wurde.

In einem Netzwerkrouter kommen Pakete an, werden aber nicht immer sofort weitergeleitet, selbst wenn die ausgehende Verbindung frei ist. Je nach Routerrichtlinie kann der Router das Paket etwas verzögern, in der Hoffnung, dass noch weitere Pakete aus anderen Quellen [oder aus derselben Quelle bei UDP] eintreffen, damit der Router die kleineren Pakete zu einem großen Paket zusammenfassen kann, das effizienter über die ausgehende Verbindung übertragen werden kann.

Bei Festplatten könnte diese „Verzögerung“ durch die Cache-Richtlinie einer bestimmten FS-Schicht charakterisiert werden. Mit anderen Worten: Wenn eine Anfrage zur Zeit T bei einer Schicht ankommt, könnte sie die Schicht nicht bei T+1 verlassen und bei T+1 bei der nächsten Schicht ankommen, sondern bei T+n. Eine FS-Cache-Schicht könnte dies tun, damit sie eine Suchreihenfolgeoptimierung/-sortierung durchführen kann.

Das Verhalten, das Sie beobachten, ist einem TCP-Socket sehr ähnlich, der sein Fenster aufgrund einer Überlastung reduziert hat.

Ich denke, es ist wichtig, die Tests aufzuteilen. Im Moment führen Sie Lese- und Schreibvorgänge durch. Und Sie wissen nicht, was der limitierende Faktor/Engpass ist. Ich denke, es wäre hilfreich, die Tests in Lese- und Schreibvorgänge aufzuteilen. Ein ordentliches Benchmark-Programm wird das wahrscheinlich tun. Was ich befürworte, ist eine ausgefeiltere Version von [das sind nur grobe Beispiele, nicht die genauen zu verwendenden Argumente]:

Für das Schreiben, Zeit dd if=/dev/zero of=/whatever_file count=64g
Zum Lesen, Zeit dd wenn=/was auch immer von=/dev/null Anzahl=64g