Probieren Sie Ionic-ing oder Nice-ing für den Kopiervorgang aus. Das Problem ist darauf zurückzuführen, dass IO die gleiche Priorität wie die GUI erhält, was sich bei einem Desktop auf die wahrgenommene Reaktionsfähigkeit auswirkt.
Dazu gibt es derzeit ein Ubuntu-Brainstorming.
Linux hat seit langem ein Problem mit Programmen, die den gesamten "schmutzigen" Cache-Speicher des Systems in Beschlag nehmen. Was passiert ist, dass der Kopierprozess den Schreibcache mit den Dateidaten füllt, die er kopiert, und das sehr schnell. Wenn also Firefox auftaucht und schreiben muss, muss es zuerst auf Dirty Buffer Space oder einen verfügbaren Schreib-Slot in der Disk-Warteschlange warten. Während des Wartens konkurriert es mit dem Kopierprozess und dem pdflush-Thread des Kernels, der Daten aus schmutzigen Puffern in die Schreibwarteschlange der Festplatte verschiebt.
Firefox hat in diesem Szenario noch ein weiteres Problem. Es verwendet SQLite, um seine Lesezeichen, den Verlauf und andere Dinge zu speichern. SQLite ist eine ACID-kompatible Datenbank und verwendet ein Transaktionssystem, bei dem Festplattenschreibvorgänge auf die Festplatte geleert werden . Es muss also nicht nur auf Pufferplatz warten, sondern auch darauf, dass die Festplattenwarteschlange, die voller kopierter Dateien ist, geleert wird, bevor es einen erfolgreichen Schreibvorgang bestätigen kann.
Es ist viel passiert von Optimierungen am Linux-Festplattenwarteschlangen- und Puffersystem. In fast jeder Kernel-Version gibt es Änderungen. Probieren Sie eine der neueren Versionen aus. Sie können auch versuchen, die sysctl-Werte zu optimieren. Ich mag diese:
vm.dirty_writeback_centisecs = 100
vm.dirty_expire_centisecs = 9000
vm.dirty_background_ratio = 4
vm.dirty_ratio = 80
Sie können auch versuchen, die Anzahl der Slots in der Festplattenwarteschlange zu optimieren. Dieser Wert steht in /sys/block/sda/queue/nr_requests . Sie müssen sda ersetzen mit was auch immer Ihr Antrieb wirklich ist. Mehr Slots bedeuten mehr Möglichkeiten, IO-Anforderungen zusammenzuführen, und der CFQ-IO-Scheduler kann mit Prioritäten besser arbeiten. Weniger Slots bedeuten normalerweise eine kürzere Wartezeit, um für synchrone E / A wie SQLite-Transaktionen auf die Festplatte geschrieben zu werden. Weniger Slots bedeuten auch eine kürzere Wartezeit, um Lese-IO in die Festplattenwarteschlange zu bekommen, wenn ein schreibintensiver Prozess die Warteschlange vollständig mit Schreib-IO füllt.