Linux: Intermittierende System Freezes ohne erkennbare Fehlermeldung

Der Artikel adressiert gleich mehrere Aspekte, nicht nur den System Freeze. Es geht auch um die System Performance, liefert Beispiele wie man SSDs zeitgesteuert aufräumt und zeigt auf warum man die Mount Option discard oft nicht benutzen sollte. 

Angefangen hat alles mit den nicht nachvollziehbaren System Freezes. Ich fand keinen Weg die zu reproduzieren, die traten einfach auf, sprich das System blieb stehen. In keinem Log fand sich eine Fehlermeldung. Auch diverse Konsolen die ich auf einem zweiten Rechner via SSH mitlaufen lies zeigten absolut nichts Ungewöhnliches an. Nach langem Wühlen und intensiver und langer Recherche wurde zumindest auf dem fraglichen System die Ursache gefunden. Es war die SSD, genauer der Umgang mit ihr. 

Um das zu verstehen muss ich ein wenig ausholen. Eine SSD arbeitet anders wie eine normale Festplatte, in vielerlei Hinsicht. Löscht man eine Datei, dann bleiben die Blöcke erst einmal belegt obwohl die Datei nicht mehr benutzt wird da sie ja gelöscht wurde. Eine SSD muss sich also aufräumen, sprich die unbenutzten Blöcke freigegeben. Das erleichtert der Platte auch die Garbage Collection und sorgt damit für eine bessere Performance und längere Lebensdauer, soweit die Theorie. Dazu wird die Trim Funkton der SSD unbedingt benötigt. Der Linux Kernel unterstützt ab Version 3.8 Trim in den meisten Dateisystemen. Jetzt gibt es zwei Arten von Trim, Continuous also ständiges und Periodisches Trim also zeit gesteuert und genau hier liegt das Problem. 

Wird eine Festplatte mit der Option discard gemountet, egal ob über eine Mount Unit oder fstab findet ein Continuous Trim statt. Also wird eine Datei gelöscht, werden die unbenutzten Blöcke sofort frei gegeben. Klingt erst einmal gut, ist es aber bei genauerem Hinseehen gar nicht. Zum einen wird von SATA erst ab Version 3.1 Continuous Trim überhaupt unterstützt. Ältere SSDs und BIOS Systeme können damit also nicht umgehen und die Folge ist oft ein System Freeze unter einer gewissen I/O-Last. Aber auch moderne SATA SSDs sind von dem Problem offensichtlich nicht frei. Das fragliche System lief mit Kernel 4.14.8 und einer modernen SSD die kein Jahr alt war. Unter Hochlast von I/Os also vielen konkurrierenden Zugriffen auf den gleichen Bereich blieb das System einfach stehen. Keine Kernel Panic, nichts. Es stand einfach still. Der klassische Freeze. 

Die Ursache des Ganzen war die discard Option die beim Mount verwendet wurde, ich weiß das wird oft empfohlen, deswegen schreib ich ja den Artikel. Also, die discard Option sorgt für ein Continuous Trim bei einer gelöschten Datei, oder überhaupt gelöschten Daten, werden die belegten Blöcke sofort frei gegeben. Wenn aber gleichartige Datenbereiche schnell wieder beschrieben aber auch gleich gelöscht werden sollen kommt die Firmware der SSD offenbar durcheinander, sie bleibt hängen. Immerhin soll sie die Blöcke sofort freigeben aber sofort auch wieder wieder beschreiben. In der Folge führt der Kernel eine gültige I/O Operation aus die aber nie ankommt weil die SSD steht. Der I/O wird nie beendet, die Maschine wartet und fertig ist der Freeze ohne Fehlermeldung. Mit einem derart hängenden System kann man überhaupt nichts mehr anfangen auch der Wechsel auf ein TTY mittel STRG ALT F4 (beispielsweise) funktioniert nicht mehr. Es geht ja kein einziger I/O mehr weil das System noch immer auf den einen wartet der nie beendet wird. Der gesamte Kernel steht also fest und nichts regt sich mehr. In dem Zustand kann auch keine Fehlermeldung mehr geschrieben werden. 

Auf solchen System ist es also besser discard nicht zu benutzen um zum Periodic Trim zu wechseln. Der Trim wird also zyklisch ausgeführt und nicht ständig, was mich zum Performance Thema bringt. Muss sich eine SSD ständig aufräumen ist ein Teil der Leistung blockiert um normale Operationen auszuführen, der Controller der Platte hat also eine ständige Grundlast. Zu deutsch, die Platte wird langsamer. Der Unterschied ist meistens fühlbar und nicht auf Benchmarks angewiesen und kann je nach SSD auch signifikant sein. Daher verzichtet Canonical auf die discard Option ganz und arbeitet nur mit periodischem Trim. Wird unter ubuntunoiden Systemen also eine SSD erkannt wird nicht die discard Option gesetzt. Wer die unbedingt will muss das dort manuell tun. Unter Arch Linux sieht es anders aus weil die Arch Schiene systemd reinrassiger implementiert hat wie die ganzen Unbuntus samt Ableger. Der der Wechsel zum periodischen Trim bringt demnach sehr oft auch einen Geschwindigkeitsvorteil mit der teilweise nicht unerheblich ist. 

Nur wie kommt man zum periodischen Trim? Es gibt zwei Wege. Zum einen der gute alte Cronjob, so machen es Ubuntu & Co. Oder eben über systemd, der die Zukunft darstellt. Zum Thema systemd will ich aber noch einen separaten Artikel schreiben. Fangen wir mit den ubuntunoiden Systemen an, bespielesweise mit Linux Mint. Mint bringt einen systemd mit, wie alle großen Distributionen, arbeitet hier aber noch über den guten alten Cron. Demzufolge findet sich das Trim Script fstrim im Verzeichnis /etc/cron.weekly. Daher setzten diese System auch nicht die Mount Option discard ein, die Platte wird ja einmal pro Woche aufgeräumt. Das Script selber ist winzig: 

#!/bin/sh
# trim all mounted file systems which support it
/sbin/fstrim --all || true

Unter Systemen mit hoher Last kann es sinnvoll sein das Script nach /etc/cron.daily zu verschieben. Normalerweise ist cron.weekly aber vollkommen ausreichend. Da dort mit Anacron gearbeitet wird, war das alles. einfach das Script in den passenden Ordner verschieben, das wars. 

Ein wenig anders sieht es unter reinen systemd Systemen aus. Dort ist cron eigentlich obsolet. "Cronjobs" also perdiodisch wiederkehrende Abläufe werden da als eine Kombination von Timer und Service Unit ausgeführt. Die Timer Unit bestimmt den Startzeitpunkt und die Service Unit beschreibt was getan werden soll. Die doch recht kryptische Crontab oder Anacron kann ignoriert werden. 

Bei Arch finden sich die Beispiele der Units im Paket util-linux und auch dort geht man von einer wöchentlichen Periode aus. Will man das ändern muss die Timer Unit editiert werden. Das hier ist die Timer Unit  unter Antergos: 

Description=Discard unused blocks once a week
Documentation=man:fstrim

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

Und hier die die Service Unit dazu: 

Description=Discard unused blocks

[Service]
Type=oneshot
ExecStart=/sbin/fstrim -av

Die Dateien heißen fstrim.timer bzw fstrim.service und lassen sich über locate leicht finden. Die verschiebt man als root am besten nach /usr/lib/systemd/system/. Man kann sie auch nach /etc/systemd/system verschieben aber ich habe beobachtet das Antergos die dann von selbst weiter schubst. Damit ist der periodische Trim aktiv und ihr habt gleich ein Beispiel wie der Ersatz von Cron aussieht. fstrim ist eingentlich überall vorinstalliert zwischenzeitlich, so das sich die Nachinstallation erübrigt. Die Ausgaben lassen sich mit journalctl überprüfen. 

Ich habe festgestellt das sowohl mein Linux Mint 18.3 Sylvia wie auch Antergos deutlich agiler wirken. Andere berichten von teils dramatischen Geschwindigkeitsgewinnen. Aber das muss man wohl selber ausprobieren.

Aber das wichtigste fehlt noch. Seit der Umstellung ist kein Kernel-Freeze mehr aufgetreten. Wer also Freeze-Probleme hat und sein Linux von einer SSD startet oder auf eine SSD swappen lässt, für den ist es allemal einen Versuch wert denke ich. 

(Visited 76 times, 1 visits today)
Facebooktwittergoogle_plusredditpinterestlinkedinmail

Schreibe einen Kommentar

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden. Damit diese Seite funktioniert ist es notwendig kleine Dateien (genannt Cookies) auf deinem Computer zu speichern. Zudem erhöhen die Cookies den Bedienungskomfort für dich. Google selbst verwendet Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unserer Website zu analysieren. Außerdem gibt Google Informationen zur Nutzung unserer Website an dessen Partner für soziale Medien, Werbung und Analysen weiter. Die geschieht über die eingeblendeten Werbebanner. Wenn du diese Seite benutzt stimmst du der Nutzung von Cookies zu. Über Ihre Browsereinstellungen kannst du entscheiden ob Cookies angenommen werden oder nicht. Auch kannst du Cookies jederzeit und auch gezielt über den Browser löschen. Due kannst den Browser auch so konfigurieren das beim Schliessen alle Cookies automatisch gelöscht werden. Weit über 90% aller Webseiten setzen Cookies. Jedoch werden wir seit dem 26. Mai 2012 per EU Datenschutz Regelung dazu aufgefordert zuerst deine Zustimmung einzuholen.

Schließen