Raspi 4 + InfluxDB + SSD = SSD-Killer?

  • Hallo zusammen,

    ich betreibe eine Raspi 4 8GB mit IOTstack im 24/7 Betrieb mit USB-SSD und boote auch von dieser ohne eine SD-Card zu nutzen.

    Einer der Docker ist eine InfluxDB. Diese bekommt von mehreren Sensoren teilweise sekündlich Werte. Da es jeweils nur kleine Datenmengen sind ist die 256 GB SSD bisher nur zu 31% gefüllt.

    Weitere Dienste/Container wie Nextcloud, Grafana und Wireguard werden wohl kaum zum Datenaufkommen beitragen.

    Soweit so gut. Das System lief über Monate stabil. :thumbup::thumbup::thumbup:

    Vor einiger Zeit konnte ich dann nicht mehr auf das System zugreifen. Das LED an der SSD war aus, normalerweise leuchtet es bzw. blinkt bei Datenaustausch.

    Nach dem Neustart via Netzteil lief alles wieder wie eh und je. :thumbup:

    In der Folge hat sich das System dann noch zwei mal in Abständen von ein paar Tagen aufgehängt.

    Ich habe die SSD dann mal an einen PC gehängt und mit CrystalDiskInfo die SMART-Werte angeschaut.

    Danach wurden 46 TB geschrieben (in 6400 Betriebsstunden). Und nur 40GB gelesen.

    Das ist deutlich mehr als mein PC in vielen Jahren (nicht 24/7 Betrieb natürlich)

    Nun frage ich mich wie lange das nun wohl noch gut geht :?:

    Momentan läuft der Raspi wieder seit gut einer Woche ohne Probleme.

    Kann ich der InfluxDB irgendwie beibringen erstmal in eine RAM-Disk zu schreiben und die Daten auf der SSD erst nach sagen wir einer Stunde zu schreiben oder so? :conf:

    Das müsste doch ein Standard-Problem sein, oder nicht?

    RETENTION POLICY hab ich keine bewusst angelegt. Es scheint aber eine zu geben, aber ich weiß nicht genau was die macht

    name duration shardGroupDuration replicaN default

    ---- -------- ------------------ -------- -------

    autogen 0s 168h0m0s 1 true

    Die hab ich wohl unbewusst angelegt.

    Bin mal gespannt was euch dazu einfällt.

    Gruß Claus

  • Könntest du deine Scripte nicht so anpassen, dass diese eine Liste anlegen der ausgelesenen Werte und diese einmal in einem definierten Zeitabstand in einem Durchgang in die Datenbank schreiben? Wenn nicht wäre vielleicht auch eine mechanische Festplatte eine Lösung je nach Umgebung oder das schreiben in einer Datenbank die sich auf irgendeinen Server befindet.

  • Könntest du deine Scripte nicht so anpassen, dass diese eine Liste anlegen der ausgelesenen Werte und diese einmal in einem definierten Zeitabstand in einem Durchgang in die Datenbank schreiben? Wenn nicht wäre vielleicht auch eine mechanische Festplatte eine Lösung je nach Umgebung oder das schreiben in einer Datenbank die sich auf irgendeinen Server befindet.

    Wie die Daten auf die Datenbank eingehen könnte man sicher optimieren, aber das wird aufwändig, da die Datenbank ja gerade der zentrale Sammler sein soll. Das ganze auf irgend einen Server im Internet zu packen fällt aus Ideologiegründen aus. Denn nur die eigene Cloud ist eine gute Cloud :) und eine Festplatte wollte ich nicht wegen Stromverbrauch und irgenwann wird die mechanisch auch verschleißen. Bei 8 GB RAM muss doch was möglich sein. Gruß Claus

  • Moin Claus,

    influxdb hat einen Cache. Muß "nur" eingerichtet werden.

    Suche in der Dokumentation mal nach "cache".

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Moin!

    Allerdings habe ich mit meiner influxdb auch keine Killprobleme

    Ich auch nicht. Obwohl ich nur auf einem USB-Stick schreibe.

    Was ich auch nicht weiß ist, wenn man, so wie ich, keinen Zeitstempel mitschickt, influxDB den auch im Cache setzt.

    Aber das kann man ja probieren.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Ich habe keine Ahnung wie groß die Datenbank ist. Falls zu groß, ist mein Vorschlag obsolet.

    • RAM-Disk in der passenden Größe anlegen und die Datenbank dort lagern
    • Per Skript regelmäßig (z.B. alle 24 Stunden) den Container stoppen , die DB von der RAM-Disk auf die SSD sichern und Container wieder starten

    Eintrag in der /etc/fstab für eine RAM-Disk mit 300MB:

    Code
    tmpfs /deinRAMDiskVerzeichnis tmpfs defaults,noatime,nosuid,size=300m 0 0

    Bei mir (Pi4 m. 4GB RAM) habe ich das mit den Daten von Monitorix, sowie mit den Daten eigener Scripte so umgesetzt. Da wird unentwegt auf der RAM-Disk geschrieben, aber nachts nur einmal alles gesichert (15s Dauer). Im schlimmsten Fall verliere ich die Daten von einem Tag.

    Viele Grüße,

    Peter

  • Mal eine Frage zum Verständnis: Lohnt sich eine komplexe Datenbank überhaupt um Sensordaten zu erfassen? Ich sehe es oft das große Datenbanksysteme genutzt werden um ein paar Datensätze zu speichern für die eigentlich eine SQLite vollkommen ausreichen würde. Zumal diese Datenbankserver ja auch einiges an Overhead produzieren sowohl an Ram Verbrauch wie auch Schreibzugriffen was man bei Singleanwendungen eigentlich nicht braucht.

    Gut verschiedene Systeme haben spezielle Vorteile wie InfluxDB, aber die Frage ist ob man diese Vorzüge in einem Szenario braucht. Gibt es also einen bestimmten Grund warum viele komplexe Datenbanksysteme nutzen für simpelste Aufgabe oder ist es in vielen Fällen nur Unwissenheit, oder bedenke ich gerade etwas nicht?

  • Hallo InterGeek,

    Mal eine Frage zum Verständnis: Lohnt sich eine komplexe Datenbank überhaupt um Sensordaten zu erfassen? Ich sehe es oft das große Datenbanksysteme genutzt werden um ein paar Datensätze zu speichern für die eigentlich eine SQLite vollkommen ausreichen würde. Zumal diese Datenbankserver ja auch einiges an Overhead produzieren sowohl an Ram Verbrauch wie auch Schreibzugriffen was man bei Singleanwendungen eigentlich nicht braucht.

    Gut verschiedene Systeme haben spezielle Vorteile wie InfluxDB, aber die Frage ist ob man diese Vorzüge in einem Szenario braucht. Gibt es also einen bestimmten Grund warum viele komplexe Datenbanksysteme nutzen für simpelste Aufgabe oder ist es in vielen Fällen nur Unwissenheit, oder bedenke ich gerade etwas nicht?

    die Sachlage ist sehr vielschichtig. Da kommen viele unterschiedliche Dinge zusammen.

    Da ist z.B. der Typ, der um 2013 herum in einem Tutorial gezeigt hat, wie man mit einer RoundRobin-Datenbank (RRD) Daten sammeln und graphisch aufbereitet anzeigen kann.

    Die meisten Zeitgenossen neigen (leider) dazu, vorhandene Tutorials unreflektiert nachzumachen. Somit setzt sich in den Köpfen vieler fest, irgendwelche oft banalen Daten anzuzeigen ginge nur über eine Datenbank.

    Ich dagegen habe echte Freude beim Programmieren eigener Ideen. Ich brauche dafür keine Datenbank. Mein Favorit sind weiterhin (doppelt) verkettete & indizierte Listen.

    Wenn ich da einen zeitlichen Verlauf benötige, dann programmiere ich eine WorldTo2D/3D-Transformation bzw. (da ich als Programmierer grundsätzlich auch einen großen Batzen Faulheit mein Eigen nenne) übernehme ich da Funktionalitäten / Module / Libraries aus früheren Projekten.

    Wenn die Datensätze der verketteten Listen so beschaffen sind, dass dort recherchierbare Felder enthalten sind, dann kommen Such- und Sortier-Algorithmen dazu.

    Ich wundere mich auch immer, wieso jemand für richtig banale Dinge Datenbanken vollballert und seine Datenträger ruiniert (weil er sich bei der initialen Einrichtung zu wenig Gedanken gemacht hat oder sich so wenig mit der Materie beschäftigt hat, dass die Einrichtung nur laienhaft erfolgte).

    Irgendeine (überzogene) Anwendung wird installiert, um an die Daten heranzukommen. Über eine Schnittstelle gelangen die Daten in eine Datenbank. Über eine Schnittstelle zu einer anderen Anwendung werden die Daten angezeigt. Dürfte alles zu Lasten der SD oder SSD gehen (wenn man nichts anderes festgelegt hat).

    Mich wundert es wenig, dass da Hardware zerschossen wird.

    In meinen seit vielen Jahren laufenden Anwendungen gibt es nur:

    • eine Datenquelle (Sensoren etc.)
    • selbstentwickelte Anwendung, die über (doppelt) verkettete und indizierte Listen die Daten aufnimmt
    • Funktionalität rund um die Daten
    • gespeicherte Datensätze

    Es gibt bei mir also nur eine Software und eine Datendatei.


    Es hat aber jeder seinen eigenen Grad der Erkenntnis, der ihm die Beurteilung der Sachverhalte erlaubt.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (7. April 2022 um 11:37)

  • Ich sehe es oft das große Datenbanksysteme genutzt werden um ein paar Datensätze zu speichern für die eigentlich eine SQLite vollkommen ausreichen würde.

    Das trifft bei mir genau so zu.

    Ich lese einen Sensor aus, um dann 2 Werte in meine Datenbank zu aktualisieren. Diese werden auch nicht neu angelegt, sondern die vorhandenen überschrieben. Meine Datenbank besteht sozusagen aus einer Tabelle, die nur eine Zeile hat da eben die Daten nicht neu rein geschrieben werden sondern per Update überschrieben.

    Ich werde mir das SQlite mal anschauen, vielen Dank für den Hinweis.

    Gruß

    Tamia

  • Mein Favorit sind weiterhin (doppelt) verkettete & indizierte Listen.

    Das ist definitiv die schnellste und resourcenschonendste Methode. Sie funktioniert aber nur solange die Anzahl der zu bearbeitenden Daten in den Hauptspeicher passt. In dem Moment wo das System zu swappen anfaengt weil die ganzen Daten nicht mehr reinpasst wird alles langsam und auch resourcenfressend.

    Auch kann nicht jeder programmieren oder hat die Zeit und Lust das zu programmieren. Dann nutzt man eben vorhandene Tools die weil sie sehr universell einsetzbar sein sollen natuerlich nicht so effizient sein koennen. Dafuer braucht man dann nicht programmieren zu koennen und die entsprechende Zeit investieren.

    Bei mir werden von ca 20 Sensoren jede Minute Messdaten in eine InfluxDB geschrieben. Momentan sind um die 20 Millionen Daten in der DB die ich komfortabel per Grafana analysieren kann. Allerdings werden die Daten nicht auf eine SSD geschrieben sondern eine Harddisk :shy: LTW ist 2TiB. 46TB ist sehr viel bei Dir. Ich koennte mir denken dass Deine Daten die Du in die DB reinsteckst ungeschickt gewaehlt sind so dass fuer jede Messung immer wieder ein neuer Datensatz angelegt wird. Das ist z.B. der Fall wenn Du jedes mal einen Timestamp oder sonstigen unique Key (z.B. eine UUID) mit den Daten ablegst.

  • Vielleicht bringt

    Code
    docker stats

    etwas Licht ins Dunkel.

    Weitere Dienste/Container wie Nextcloud, Grafana und Wireguard werden wohl kaum zum Datenaufkommen beitragen.

    Irgend etwas schreibt die SSD voll, bzw. hat hohe Schreibzyklen.

    Btw. Nextcloud nutzt auch eine Datenbank.

  • Danke für eure Ausführungen, auch besonders dir Andreas

    Ich lese einen Sensor aus, um dann 2 Werte in meine Datenbank zu aktualisieren. Diese werden auch nicht neu angelegt, sondern die vorhandenen überschrieben.

    Ja da ist übertrieben eine nette Formulierung :^^:

    Ich würde wenn es mein Projekt wäre mir folgende Frage stellen: Ändern sich die Werte der Sensoren bei jedem auslesen? Bei einem Temperatursensor in einem Keller als Beispiel wird die Temperatur ja nicht innerhalb weniger Sekunden mehrfach schwanken.

    Du könntest Schreibzugriffe schon reduzieren mit einem einfachen Trick. Prüfe ob der neue Wert = der alte Wert ist. Wenn ja, dann musst du diesen nicht erneut schreiben. Wenn es keine Historie der Werte geben soll, dann wäre selbst SQLite schon zu viel. Einfach den Wert in eine Textdatei schreiben und fertig. Diese Textdatei könnte ja auch fiktiv auf einem NAS oder in der Cloud liegen.

  • Ändern sich die Werte der Sensoren bei jedem auslesen?

    Ja das tun sie, wenn vom Sensor ein Signal kommt, wird in der Datenbank +1 "gerechnet" und es wird die aktuelle Temperatur vom Raspberry abgespeichert und die ändert sich auch meistens, da ich auf eine Nachkomme stelle den Wert abspeichere. Das zumindest könnte ich ändern, denn ob nun 45.1 oder 45.6 stehen habe ist doch eher uninteressant.

    Gruß

    Tamia

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!