Ausgabe

Question

Ausgabe

Ich habe vor Kurzem Ubuntu 16.04 LTS (Kernel 4.8.0-52) auf einem Lenovo T460p mit einem i7-6820HQ, 32 GB RAM und einer 512 GB Micron 1100 SSD installiert. Ich habe während der Installation das Kontrollkästchen für die vollständige Festplattenverschlüsselung aktiviert und das Standardpartitionierungslayout verwendet. Im Allgemeinen ist die Leistung großartig.

Jedoch, mit der Zeit dauerte die Ausführung meiner Builds etwa doppelt so lange. Außerdem kommt es während der Teile des Builds, in denen große Dateien geschrieben werden, bei allen (nicht-Build-)Aufgaben, die Festplatten-E/A erfordern, zu langen Wartezeiten. Dazu gehört das Starten neuer Programme, das Laden von Seiten in Firefox usw. In Firefox kann ich beispielsweise durch die Benutzeroberfläche navigieren, zwischen Registerkarten wechseln und alles ist in Ordnung. Aber wenn ich einem Link folge, bleibt die gesamte Benutzeroberfläche hängen, bis sich alles beruhigt hat.

Zusammenfassend lässt sich also sagen, dass Builds nach einer gewissen Zeit plötzlich länger dauern und der Computer an bestimmten Punkten während des Builds im Grunde unbrauchbar ist.

Was kann ich tun, um dieses Problem zu diagnostizieren oder zu beheben?

Informationen zur Fehlerbehebung

• Ich starte nicht oft neu, daher läuft das System oft mehrere Tage, bevor ich auf dieses Problem stoße. Sobald ich es treffe, versuche ich ein bisschen, das Problem herauszufinden, und starte dann neu, damit ich weiterarbeiten kann.

• Das einzige, was das Problem löst, ist ein Neustart des Computers. Ich habe versucht, alle Anwendungen zu beenden, mich ab- und wieder anzumelden und den Puffercache zu löschen (die Theorie besagt, dass die Festplattensynchronisierungen häufiger stattfanden, da er Speicherplatz verbrauchte), aber nur ein Neustart funktioniert.

• Als Versuch habe ich versucht, die Lösung zudiese Antwortaber es gab keine Verhaltensänderung.

• Beim Ausführen iotopwird angezeigt, dass der dmcrypt_writeThread 99 % I/O verwendet, wenn ich die Probleme habe. Wenn ichnichtWenn ich das Problem habe, sehe ich auch, dmcrypt_writedass es mit einem relativ hohen IO-Prozentsatz nach oben springt, aber es bleibt nicht sehr lange dort.

• Wenn ich es ausführe dd if=/dev/urandom of=$HOME/bigfile bs=10k count=200k; syncund alles normal funktioniert, dmcrypt_writespringe ich für ein oder zwei Sekunden nach oben, aber das dauert bei weitem nicht so lange wie während eines meiner Builds.

• Ein vollständiger Build generiert etwa 1,4 GB Daten. Es handelt sich um ein Java-Projekt mit mehreren Modulen. Es werden also viele kleine Dateien erstellt, plus einige größere JAR-Dateien, die all diese kleinen Dateien zusammenfassen.

• Es ist immer genügend Speicher verfügbar und die Swap-Partition wird nicht verwendet.

• Ich habe Kollegen mit ähnlichen Computern (T460p), die ebenfalls Ubuntu verwenden und bei denen dieses Problem nicht auftritt. Sie scheinen alleandersAllerdings SSD-Marke/Modelle.

Aktualisieren

Das Problem ist gerade erneut aufgetaucht, daher habe ich auf Grundlage der Antwort auf diese Frage weitere Tests durchgeführt.

• Das Dateisystem ist immer noch nicht mit der discardOption gemountet, also habe ich stattdessen fstrimangenommen, dass es in etwa so ist, als ob die discardOption aktiviert gewesen wäre.
• Ich habe nicht genügend Zeit gemessen, als das Problem erstmals auftrat, aber nach dem Ausführen fstrimschienen die Build-Geschwindigkeiten wieder normal zu sein ...AberNachdem der Build abgeschlossen ist, dmcrypt_writegreift der Thread ein und macht das System für eine gewisse Zeit unbrauchbar. Insgesamt scheint die Gesamtzeit für den Build und bis das System nutzbar wird, ungefähr gleich zu sein wie zuvor.
• Ich habe /proc/sys/vm/dirty_ratioauf 2 und /proc/sys/vm/dirty_background_ratio1 gewechselt und einige Builds ausgeführt. Die Builds dauerten länger als normal – ungefähr so ​​lange wie beim letzten Mal, als ich auf dieses Problem gestoßen bin, aber das System schien nicht mehr so ​​oft abzustürzen. Als ich es wieder auf 20 und 10 geändert habe, war das oben beschriebene Verhalten wieder da.
• Bei einem sauberen Neustart habe ich die Einstellungen /proc/sys/vm/dirty_ratioauf 2 und /proc/sys/vm/dirty_background_ratio1 versucht und die Zeit war mit 20 und 10 vergleichbar.

Answer 1

Ich hatte ein ähnliches Problem unter Debian 10+11: Wenn ich große Schreibvorgänge auf der LUKS-Festplatte durchführte, fror mein gesamtes System für einige Zeit ein, reagierte dann wieder und fror dann erneut ein ...

Ich musste jedoch nicht neu starten – ich musste nur warten, bis der Schreibvorgang abgeschlossen war.

Wie ScumCoder schrieb, ist ein Fix verfügbar. Ab Kernel 5.9 ist der Fix in den Kernel integriert.

Der folgende Befehl hat das Problem für mich behoben:

cryptsetup --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh nvme0n1p3_crypt

Ich habe meinen Datenträger mit dem Namen "nvme0n1p3_crypt" mit dem Befehl extrahiertdmsetup table

Ich habe mich inspirieren lassen vonhttps://wiki.archlinux.org/title/Dm-crypt/Specialties#Disable_workqueue_for_increased_solid_state_drive_(SSD)_performance

Nach dem Fix sind meine Schreibvorgänge viel schneller.

Answer 2

Ich habe genau das gleiche Problem wie Sie und eine kurze Recherche ergab diesen Beitrag:

https://blog.cloudflare.com/beschleunigung-der-linux-festplattenverschlüsselung

Der CloudFlare-Mitarbeiter hat den Linux-Quellcode gründlich durchforstet und ist zu dem Schluss gekommen, dass die aktuelle dmcryptImplementierung die Ursache ist. Er löste das Problem, indem er den entsprechenden Teil des Kernels im Wesentlichen neu schrieb.

Soweit ich weiß, gibt es nur zwei Möglichkeiten, die Verlangsamung zu beseitigen: (1) seine Version des Kernels zu kompilieren oder (2) ab und zu einen Neustart durchzuführen (wie Sie sagten). Ich habe mich für Letzteres entschieden.

Answer 3

Ich weiß nichts Genaueres über LUKS, aber bei allgemeinen E/A-Problemen auf einer SSD stellen Sie sicher, dass „Discard“ für Ihre FS-Einbindung aktiviert ist. Grep Discard /proc/mounts könnte z. B. auch (als Root) „echo 1 >> /proc/sys/vm/dirty_background_ratio; echo 2 >> /proc/sys/vm/dirty_ratio“ versuchen. Dadurch initiiert das System die E/A eher, wenn weniger Datenrückstände zum Ausgeben vorhanden sind.