Verringerung der Übertragungsrate beim Kopieren großer Datenmengen

Ich verwende ein Ubuntu 16.04.3 LTS-System (4.10.0-40-generic) mit zwei Festplatten und mehreren Partitionen auf jeder Festplatte. Wenn ich Daten (<5 GB) zwischen die beiden Festplatten kopiere, erhalte ich eine Übertragungsrate von ca. 70 MB / s. Wenn ich jedoch versuche, eine große Datenmenge (> 30 GB) von einer Festplatte auf eine andere zu kopieren, stelle ich mehrere Leistungsprobleme fest.

Meine Frage ist, ob dieses Verhalten normal ist und auf Linux-Systemen zu erwarten ist.
Kann mir jemand dies erklären und mir raten, wie ich diesen Leistungsabfall vermeiden kann?

Im Folgenden werde ich meine Beobachtungen beschreiben. Im Beispiel habe ich eine Disk-Image-Datei mit 54 GB von sda8 (325 GB Partition) nach sdb8 (1,6 TB Partition) kopiert.

1) Die Übertragungsrate nimmt ab und iowait steigt
Wenn ich versuche, mehr als 50 GB zu kopieren, stelle ich fest, dass die Übertragungsrate allmählich abnimmt. Ich überwache die Leistung mit Blicken, oben, iotop und iostat. Bei 30 GB Fortschritt ist die Übertragungsrate auf 58 MB / s, bei 46 GB auf 36 MB / s und bei 52 GB auf 12 MB / s gesunken. Danach beginnt die Übertragungsrate wirklich zu schwanken und fällt unter 1 MB / s. Gleichzeitig sehe ich, dass iowait von anfänglich 0% auf 62% am Ende steigt. Während des Kopierens der Festplatte hat SD8 einen "Besetzt" -Prozentsatz zwischen 40% und 60%. Die Festplatten-SDB ist ständig zu 100% ausgelastet. Nicht nur die Übertragungsrate sinkt, auch mein System reagiert weniger schnell. Ich erwarte, dass der Iowait die Ursache dafür ist.
Ist das normales Verhalten? Wie kann der Leistungsabfall vermieden werden?

2) IOwait bleibt nach dem Kopieren hoch Nach Beendigung des Kopiervorgangs
stelle ich fest, dass iowait immer noch hoch ist und allmählich auf normale Werte abfällt. Dies dauert einige Minuten. Ich denke, dass während dieser Zeit Daten immer noch mit einer Geschwindigkeit von 1 oder 2 MB / s in sdb geschrieben werden. Bei Verwendung von iotop sieht es so aus, als würde der Prozess "jdb2 / sdb4-8" das Schreiben dieser Festplatte verursachen. Während der Zeit, in der IOwait abnimmt, leidet mein System immer noch unter einer schlechten Reaktionsfähigkeit. Es ist auch zu sehen, dass die Festplatte sda ​​nicht mehr ausgelastet ist, die Festplatte sdb jedoch immer noch zu 100% ausgelastet ist.
Was führt dazu, dass mein System nach dem Kopieren einige Minuten lang schlecht reagiert?
Kann das vermieden werden?

3) Das Kopieren vom Netzlaufwerk erhöht die Auswirkungen
Wenn ich versuche, von meinem Synology NAS auf meine lokale Festplatte (sdb8) zu kopieren, sind die Auswirkungen noch schlimmer. Zuerst wird das Netzlaufwerk an mein System gemountet und dann wird der Kopiervorgang gestartet. Zunächst wird auch eine Übertragungsrate von 70 MB / s realisiert, die Übertragungsrate muss jedoch schneller abfallen. Nach einigen GB ist die Übertragungsrate weit unter 1 MB / s gefallen. Das Kopieren wurde per Drag & Drop von Nautilus, Befehl "cp", Befehl rsync, FreeFileSync-Anwendung versucht, aber alle zeigten eine schlechte Leistung.
Was könnte die Ursache dafür sein, dass die Auswirkungen auf die Leistungsminderung bei Netzwerklaufwerken schlechter sind?

Zusätzliche Informationen
Während des Kopierens wurde "iostat -dx 5" verwendet, um die Festplattenleistung zu überwachen. Etwa 5 GB Überwachung des Kopierfortschritts zeigen:

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00     0,00  530,40    0,00 68064,80     0,00   256,65     1,62    3,06    3,06    0,00   1,63  86,72
sdb               0,00 18767,20    0,20  112,40    23,20 73169,60  1300,05   144,32 1345,39  308,00 1347,23   8,88 100,00

Wenn der Kopiervorgang auf ca. 52 GB fortgeschritten ist, wird Folgendes angezeigt:

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00     0,00   64,60    0,00  8268,80     0,00   256,00     0,22    3,41    3,41    0,00   1,76  11,36
sdb               0,00  1054,40    0,20   10,60     6,40  6681,60  1238,52   148,56 9458,00    0,00 9636,45  92,59 100,00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0,00     0,00   50,20    0,00  6425,60     0,00   256,00     0,16    3,09    3,09    0,00   1,64   8,24
sdb               0,00  2905,80    0,40   17,00     8,80 10289,60  1183,72   141,86 10199,77  652,00 10424,42  57,47 100,00

Mir ist klar, dass dies mehrere Fragen sind, aber ich vermute, dass diese alle mit derselben Ursache zusammenhängen, und hoffe, dass mir jemand dies klären kann.

Leider ist dies normal und wird für Ihren Anwendungsfall für große Dateien erwartet. Ihr Fall von zwei Festplatten und einer Datei mit mehr als 50 GB beseitigt viele irreführende Diskussionen über "langsame Geräte", "langsame Busse" und "langsame Dateisysteme", und Sie haben das ungeklärte Problem einer langsamen Kopie. Sie müssen über ausreichend Speicher verfügen, um die Leistung für 30-GB-Dateien zu erzielen. Systempuffer werden verwendet, aufgefüllt und nach Abschluss Ihres Kopierbefehls schließlich auf das Ziel geleert, was das tatsächliche Timing / die realen Raten etwas erschwert (selbst der Befehl "Zeit" wird lange vor dem endgültigen Leeren der Puffer beendet.

Die einzige "Problemumgehung", die ich gefunden habe, ist die Verwendung eines "Kopier" -Befehls, mit dem Sie explizite Puffer selbst einrichten können, wie dies tar oder cpio tun können. Durch das Festlegen eines 2-MB-Puffers für tar konnte ich eine 10-MB / s-Kopie einer 50-G-Datei auf etwa 35 MB / s beschleunigen - immer noch viel langsamer als die nominalen 100 MB / s, die ich bei kleineren Dateien (oder unter Windows) erhalte.

Eine andere Problemumgehung, die möglicherweise eine bessere Lösung darstellt, besteht darin, das Nocache-Paket zu installieren und das Ziel der Nocache-CP-Datei zu verwenden, um das Füllen der Systempuffer und das Ziehen des Systems zum Crawlen zu begrenzen. Eine 43G-Dateikopie nach / dev / null lief mit 53 MB / s, besser als der große Puffer für eine Tar-Kopie.