Anfangs hatte ich gelegentliche Probleme mit der Systemstabilität beobachtet. Insbesondere wenn ich mehrere
Dienste schnell hintereinander gestartet habe, oder große Datenmengen eingetrichtert wurden, kam es
manchmal zu einem kompletten Einfrieren des Systems. Ping-Anfragen wurden noch beantwortet, aber Logins via SSH
waren nicht mehr möglich oder haben ewig gedauert. Teilweise, wenn noch ein Bewegen via SSH möglich
war, habe ich Load-Werte von über 40 gesehen und eilig abgesetzte sudo reboot Kommandos wurden
nicht mehr ausgeführt. Das einzige, das dann noch geholfen hat, war Strom aus/Strom an.
Ich hatte als allererstes ein Problem mit dem Swapping im Verdacht. So hatte ich auch bemerkt, dass a) überhaupt eine Swap-Datei existiert und b) diese auf der SD-Karte liegt. Direkt nach dem Start der Dienste war alles gut, aber nach ein paar Zugriffen stieg der Anteil des genutzten Swap-Speichers schnell auf 40 bis 50 Megabyte an -- bei 100 Megabyte Gesamtgröße. Daraufhin habe ich die Swap-Datei auf das externe Speichermedium (zu dem Zeitpunkt noch ein USB-Stick) verschoben und auf die empfohlene Größe von 2 x RAM (also rund 2 Gigabyte) gebracht. So richtig geholfen hatte das allerdings nicht.
Die nächste Theorie war, dass sich durch eine zu hohe Spitzenlast einfach zu viele Prozesse in die Warteschlange begeben haben und das System damit nicht mehr klar kam. Allerdings wollte ich das auch nicht so recht glauben, denn das ist ja eigentlich eine Kernkompetenz eines Multitasking-Betriebssystems wie Linux; das soll sich da gefälligst nicht so anstellen...
Um dem Problem besser auf den Grund gehen zu können, habe ich ein Perl-Skript gebastelt
(sysinfo.pl), das Informationen zu Uptime, Last und Speicherverbrauch ausgibt. Dieses habe ich in
einem stündlichen Cron-Job aufrufen lassen, um ein Gefühl für die Lastverteilung zu erhalten. Als
positiven Nebeneffekt konnte ich damit auch die Zeit eingrenzen, zu der der Pi nicht mehr ordentlich tickt. Und
tatsächlich war es immer der Cron-Job nach dem Backup (bei dem alle Dienste gestoppt und danach wieder
gestartet werden), der als erstes ausblieb. Allerdings waren die Ausgaben von Last und Speicherverbrauch direkt
vor dem Backup nicht auffällig.
Nach etwas Webrecherche zum Thema Systemstabilität kam ich auf die Idee, die Temperatur des Systems genauer
zu betrachten. Es gibt ein Programm vcgencmd, das Kennwerte des Video Cores ausgeben kann, unter
anderem die Temperatur des SoC. Inzwischen habe ich herausgefunden, dass es sogar zwei Wege gibt:
vcgencmd measure_temp gibt die Temperatur des Video Cores aus (Format: temp=44.0'C)
/sys/class/thermal/thermal_zone0/temp beinhaltet die Temperatur der CPU (Format:
43470)
Beide scheinen den gleichen Wert zu liefern, was bei einem SoC mit CPU und GPU auf dem gleichen Stück Silizium durchaus Sinn ergibt (vermutlich handelt es sich sogar um den selben/einzigen Sensor). Die beobachteten Werte pendelten auffällig stabil zwischen 59 und 61 °C herum. Etwas weitere Recherche ergab, dass dies kein Zufall ist: bei 60 °C ergreift der Raspberry Pi erste Maßnahmen gegen Überhitzung und reduziert den CPU-Takt.
Ich hatte zu dem Zeitpunkt meinen Pi in einem Kunststoffgehäuse, das rundherum geschlossen war, von ein paar Luftlöchern am Boden abgesehen. Das Gehäuse hatte sich auch gut handwarm angefühlt, aber ich hatte nicht damit gerechnet, dass es dem SoC so warm wird. Als Korrekturmaßnahme habe ich ein halboffenes Aluminiumgehäuse gekauft und installiert (Suchbegriff "Raspberry Pi 3 Armor Case"). Dieses besitzt auch Wärmeleitpads für die einzelnen ICs, die eine bessere Wärmeabgabe an das Gehäuse ermöglichen, das daraufhin wie ein großer Kühlkörper wirkt. Diese Maßnahme war von Erfolg gekrönt, die Temperatur des SoC fiel um mindestens 18 Grad auf stabile 43 bis 44 °C (im Leerlauf), sodass die CPU nicht mehr runterregeln musste.
Während der Pi im alten Gehäuse kein einziges nächtliches Backup überlebt hatte, lief er im
neuen Gehäuse mehrere Tage stabil durch. Dann allerdings habe ich ihn eines morgens wieder dabei erwischt,
wie das Netzteil ein fiependes Geräusch von sich gab und der Pi nur noch sehr zögerlich antwortete.
Daraufhin habe ich den Cron-Job für das Backup so angepasst, dass direkt danach ebenfalls
sysinfo.pl aufgerufen wird, und nicht erst rund 30 Minuten später im stündlichen Raster.
Damit konnte ich sehen, dass die SoC-Temperatur direkt nach dem Backup auf rund 47 °C gestiegen war. Leicht
erhöht, aber immer noch weit weg von 60 °C.
In den folgenden Tagen habe ich weitere Änderungen an Setup und Logging durchgeführt:
load_wait.pl das so lange wartet, bis die Systemlast unter einen festgelegten Wert
fällt (wobei ich den ersten Wert aus /proc/loadavg verwende, also über eine Minute
gemittelt). Dieses rufe ich nach jedem docker-compose up und docker-compose down
auf, mit unterschiedlichen Grenzwerten.
boxctl.sh-Läufe werden in eine Datei geloggt, um auch bei einem
verstorbenen Cron-Job den "letzten Schrei" sehen zu können.
Der Erkenntnisgewinn in den folgenden Tagen war erheblich. Auf den Ergebnissen basierend habe ich unterschiedliche Kombinationen von Diensten ausprobiert und bin zu dem Fazit gekommen: kein einziger Dienst ist alleine für den Tod des Pis verantwortlich, aber alle Dienste zusammen sind zu viel. Sobald ich Gogs oder Meemo weglasse, überlebt der Pi mehr als 20 Backup-Zyklen. Alternativ kann ich Filebrowser und MyTinyTodo zusammen weglassen. (Wohlgemerkt: immer nur Leerlauf-Betrachtungen; gerade Filebrowser hat sich später im normalen Betrieb als ziemlich speicherhungrig gezeigt.)
In der Zwischenzeit hat sich durch den Umstieg auf die USB-Festplatte (Magnetplatte; noch nicht die später eingesetzte SSD) ein anderes Problem gezeigt: Meemo hält durch andauerndes Schreiben auf die Platte diese vom Einschlafen ab. Da ich aber auf niedrigen Standby-Stromverbrauch ziele (die Filebox soll schließlich rund um die Uhr laufen), war das Abschalten der Festplatte Pflicht. Am Ende einer weiteren mehrtägigen Versuchsreihe stand für mich das optimale Setup fest:
Ob das Deaktivieren des Swap-Speichers zur Stabilität beigetragen hat, oder nur das Einschlafproblem der Festplatte reduziert, ist schwer zu sagen. Was aber an diese Stelle gehört ist ein Hinweis auf die wunderschöne Webseite Linux ate my ram! die mit der Verwirrung bezüglich used, buffered, cached und free im Kontext der Speicherauslastung aufräumt. Fazit: es ist normal, dass möglichst alles an ungenutztem Arbeitsspeicher für Caching verwendet wird; dieser Speicher kann schnell frei gemacht und Applikationen zur Verfügung gestellt werden. Eine geringe Menge "freien" Speichers heißt nicht, dass das System kurz vor'm Abnippeln ist.
Als eine weitere Maßnahme, die durch die Stabilitätsprobleme inspiriert wurde, habe ich Ressourcen-Limits definiert. Diese sorgen zwar dafür, dass aus dem Ruder laufende Anwendungen recht unsanft gebremst werden (sie werden vom "OOM Killer" abgeschossen), retten aber damit das Gesamtsystem, bevor es unbedienbar wird und letztendlich einen harten Reset erfordert, was im schlimmsten Fall zu Datenverlust bei allen anderen Anwendungen führen kann.
Update: ich habe im Laufe der weiteren Entwicklung die SD-Karte gegen eine modernere ausgetauscht (eher zufällig; ich hatte die ältere Karte für ein anderes Gerät gebraucht, das mit der neueren nicht funktionieren wollte). Ursprünglich war es eine "SanDisk 16GB microSDHC Class 2 Memory Card", jetzt ist es eine "SanDisk 32GB Ultra microSDHC UHS-I Memory Card". Mit der neuen Karte starten die Dienste deutlich schneller auf und das System fühlt sich insgesamt "glücklicher" an. Auch auf meinem 1er-Pi habe ich kürzlich die SD-Karte erneuert und einen Geschwindigkeitsboost erfahren -- absolut empfehlenswert.