Ich habe auf meinem Raspberry 3 eine Instanz InfluxDB und Grafana fürs Monitoring installiert. Diese Konfiguration läuft nun bereits verhältnismäßig lange und ich stellte erste Abnutzungserscheinungen fest...

Das Problem, das immer häufiger auftrat, war anhand der Daten in Grafana deutlich zu sehen: Das Gesamtsystem zeigte immer wieder und immer häufiger Phasen, in denen die Load extrem emporschnellte und dort mehrere Minuten - bis zu 20 - verharrte.

Die Auslastung der CPU änderte sich demgegenüber nur wenig. Ich begann zu vermuten, dass die SD-Karte durch die vielen Schreibzyklen in InfluxDB begann, auszufallen und daher die Schreibvorgänge immer länger dauerten - das würde auch die hohe Load erklären, die mit einer kaum gesteigerten CPU-Last einherging: Wenn das System auf den Massenspeicher wartet, kann es keine anderen Operationen ausführen.

Dadurch kam ich darauf, dass die gestiegene Load beinahe gänzlich auf IO-Load zurückzuführen war. Das Problem daran war, dass auf meinem Raspi auch Pihole und mein eigener mein eigener DNS-Resolver für mein Heimnetz und der VPN-Endpunkt zum Zugriff von außen läuft. All diese Dinge funktionierten nicht mehr, wenn das System wieder in eine solche Phase extrem hoher IO-Load eintrat. Besonders die dann nicht mehr funktionierenden DNS-Abfragen nervten mich gewaltig.

Daher begann ich Überlegungen anzustellen, wie ich dieses Problem entschärfen und vielleicht sogar lösen könnte. Mein erster Ansatz war, herauszufinden ob wirklich InfluxDB der Auslöser war. Dafür deaktivierte ich den Dienst für einige Stunden und beobachtete das Systemverhalten. Ziemlich schnell war klar, dass ich den Auslöser gefunden hatte. Was aber löste nun die Last eigentlich aus? Auch das war recht schnell erkannt: Schuld war das Management der Retention-Policies zusammen mit dem Shard-Management. Ich konfigurierte das System so um, dass recht kleine Shards benutzt wurden, die ein Aufräumen und damit die hohe IO-Last zwar häufiger entstehen lassen würden, aber nicht mehr so lange.

Damit konnte ich das Problem ein wenig entschärfen, es blieb aber weiter bestehen.

Daher begann ich über einen radikalen Schritt nachzudenken: Wie wäre es, wenn der System-Datenträger nicht länger eine SD-Karte wäre? Ich fand einige Ressourcen im Netz, die erklärten, dass das relativ einfach zu bewerkstelligen wäre: Dann würde dieser Datenträger über USB am Raspi angeschlosen sein und die IO-Leistung des Massenspeichers deutlich über der der SD-Karte liegen.

Ich hatte noch eine alte 2.5-Zoll Magnetplatte mit 500 GB Speicherplatz im Schrank. Mein erster Versuch war der Anschluss und die Nutzung dieser Platte. Da ich allerdings an diesem Raspi auch noch einen DVB-T-Stick für die Beobachtung vorbeifliegender Flugzeuge über die Auswertung von ADS-B-Botschaften mittels SDR betreibe, bootete der Raspi nach Anschluss der Festplatte nicht einmal mehr, da die durch das Netzteil gelieferten 3 Ampere nicht zur Speisung aller Komponenten ausreichte.

Nachdem ich mich vergewissert hatte, dass 3 Ampere die Obergrenze für Netzteile für den Raspi darstellten überlegte ich mir einen Plan B: Generell gilt ja, dass SSDs als Massenspeicher weniger Strom verbrauchen als Magnetplatten. Könnte ich also eine kleine und billige SSD benutzen? Mittels einer kurzen Recherche stellte ich fest: das ginge durchaus. Ich bestellte daher - auch weil sich der Preis zu diesem Zeitpunkt annähernd halbiert hatte - einen USB-SSD-Stick zum Anschluss an den Raspi. Damit war das Strom-Problem tatsächlich gelöst (allerdings funktioniert die Konfiguration mit Raspi, SDR und SSD nach wie vor nicht an einem Netzteil, das nur 2 Ampere liefert, eines mit 2.5 Ampere konnte ich mangels Verfügbarkeit in der Bastelkiste nicht testen...) und nach Einrichtung als Systemdatenträger sank die IO-Last in den Bereich, in dem sie kein Problem für die anderen Dienste darstellte, während die CPU-Last ungefähr gleich blieb.

Zur Verdeutlichung hier noch zwei Screenshots aus Grafana:

Die Load änderte sich durch die neue Systemplatte dramatisch - auch mit den zyklischen Clean-Ups in Influx war jetzt keine Beeinträchtigung anderer Dienste mehr zu beobachten...

Die CPU-Auslastung blieb im Großen und Ganzen gleich

Ich habe noch einen Benchmark für die SSD am Raspi durchgeführt - da es sich hier um ein Modell 3 handelte, wird das Potential natürlich nicht annähernd ausgereizt...

Category                  Test                      Result
HDParm                    Disk Read                 22.97 MB/s
HDParm                    Cached Disk Read          24.72 MB/s
DD                        Disk Write                27.5 MB/s
FIO                       4k random read            1862 IOPS (7450 KB/s)
FIO                       4k random write           2370 IOPS (9481 KB/s)
IOZone                    4k read                   10884 KB/s
IOZone                    4k write                  9056 KB/s
IOZone                    4k random read            7375 KB/s
IOZone                    4k random write           9451 KB/s

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )