RAM-Probleme mit Influx und Grafana

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo liebe Forengemeinde,

    das hier ist mein erster Post. Sollte ich also die falsche Kategorie getroffen haben, verzeiht es mir bitte.

    Ich bin gerade dabei ein "smart-home" zu basteln. Der erste Schritt war in jedem Zimmer einen Temperatur- und Luftfeuchtigkeitssensor aufzustellen (mit Board: ESP8266 und Sensor: DHT22)

    Diese aktuell 5 Sensoren senden alle 10 Sekunden (natürlich unnötig oft...) ihre Daten per MQTT an einen Raspberry Pi 3B. Hier packt Node-Red die Daten in eine influx Datenbank.

    Anzeige der Daten läuft mit Grafana, dessen Service auf dem selben Pi 3B läuft.

    Nach ca. 5 Tagen fliegt mir das ganze um die Ohren. Die RAM Auslastung steigt bei der Anzeige der Daten in Grafana auf 100% und dann hängt der PI.

    Habe ein bisschen recherchiert und oft hieß es, man solle die Speicherart in influx von "inmem" auf "tsi1" stellen. Das habe ich getan, aber nach 5 Tagen war wieder Schluss.

    Jetzt ist die Frage, ob ich etwas falsch konfiguriert habe, oder ob der PI doch einfach zu schwach ist für mein Vorhaben.

    Sollte er zu schwach sein, kann man das mit einer retention policy dauerhaft lösen, oder verzögere ich da nur das Problem und es tritt dann nach 5+x Tagen auf?

    Die Daten alle 10 Sekunden bräuchte ich nur für z.B. die letzte Stunde. Ist halt eine Spielerei, wenn man z.B. sieht wie sehr und schnell sich die Luftfeuchtigkeit nach dem Duschen in der Wohnung verteilt. Alles was älter als eine Stunde ist, dürfte der PI auch mitteln und nur einen für alle 5-10 Minuten speichern.

    Ich bin über jede Form von Input sehr dankbar und hoffe mich bei anderen Themen auch hilfreich einbringen zu können :)

  • Ein Pi 3 ist mit seinem 1GB Ram schon etwas arg eng ausgelegt, denn das ganze System (Raspberry Pi OS) muss ja auch laufen und verbraucht schon einiges an RAM.


    Unter nem Pi 4 mit 4GB würde ich da nicht gehen, auch wenns vielleicht für den eigentlichen Zweck oversized sein möge aber es gibt halt keine anderen PIs mit der Speichermenge.


    Sollte dann noch irgendwas "volllaufen" (halt nach längere Zeit als 5 Tage), dann stimmt was mit dem Konzept nicht und man sollte über Datenrotation nachdenken (alte Daten raus, damit neue Platz haben).
    Hierbei käme es dann aber auch auf einen größeren Datenspeicher an (selbst ne 16GB SD Karte ist schnell und irgendwann sowieso voll).

    ;) Gruß Outi :D
    Pis: 2x Pi B (Rente) / 1x Pi B+ (Rente) / 1x Pi 2 B (Rente) / 2x Pi 3 B (RaspberryMatic / Repetier Server) / 2x Pi Zero 1.2 (B. Lite) / 2x Pi Zero 1.3 (B. Lite) / 2x Pi Zero W 1.1 (B. Lite) / 1x Pi Zero 2 (mal so, mal so) / 1x Pi 3 B+ (Tests) / 1x Pi 4 B 4GB (BW Lite (Webserver)) / Pi 400 (BW) / 1x Pi 5 (BW) / 2x Pi Pico / 2x Pi Pico W
    Platinen: Sense HAT / HM-MOD-RPI-PCB / RPI-RF-MOD / PiFi DAC+ V2.0 / TV HAT / Pi 5 Kühler HAT
    Kameras: orig. Raspberry Pi Camera Module V1 & V3 / PS3 Eye

  • Danke für deine Antwort!

    Was mich eben etwas irritiert ist, dass die DB zum jetzigen Zeitpunkt nur 200 MB groß ist. Das System benötigt insgesamt (mit Grafana, Node-Red und sonstigem) 300 MB RAM. Jetzt gehe ich in Grafana und sehe mir die Sensordaten der letzten Stunde an. Und schon ist der RAM voll, also ein Vielfaches von dem was die ganze Datenbank auf der Platte benötigt.

    Auch verstehe ich dann wohl nicht das ganze Konzept einer solchen influxdb. Also dass eine Stunde Daten am Anfang für den RAM gar keine Problem sind und nach einiger Zeit dann aber enorm viel RAM für die „selbe“ Aufgabe benötigt wird.

    Oder stellt Grafana die Anfragen falsch? Hier habe ich aber nichts an den Grundeinstellungen geändert

  • Bei mir sieht es aehnlich aus: ESPs schicken ihre Daten an mosquitto und ich nutze Grafana zum Auswerten. Allerdings lasse ich die Daten von telegraf in die InfluxDB schicken. NodeRed subscribed sich nur auf Sensortopics und wertet die Daten aus. Ich nutze aber eine Raspi4 mit 4GB Memory dazu und habe keine Probleme. Auch bei groesseren Grafanaquerries werden keine grossen Memorymengen genutzt. influx benoetigt auch um die 300MB. So wie ich das sehe wird auch alles auf einer Raspi3B ohne Probleme bei mir laufen.

    Nutzt Du fluxqueries?

  • Das macht mir doch schon mal Hoffnung, dass es eine „softwareseitige“ Lösung geben wird.

    Eine Frage dazu noch: Verwendest du als Datenbanksystem TSI, oder TSM?

    Bei mir läuft influx 1.8.9. Abfragen tu ich mit dem Standard von Grafana. Hier word standardmässig als Aggregation ja mean genommen. Und ich habe noch einen fill(linear) dazugepackt. Fehler tritt aber auch ohne das fill auf.

    Ist das schon eine fluxquery oder wäre das noch etwas anderes? :)

  • Verwendest du als Datenbanksystem TSI, oder TSM?

    Kein tsi sondern inmem

    tsm ist fuer das logging. Das habe ich ausgeschaltet. Das braucht man nur zum debuggen. Und es kostet Performance und vermutlich auch Memory.

    Bei mir läuft influx 1.8.9.

    Ist das schon eine fluxquery

    Nein. flux muss man explizit installieren.

  • Dann sehe ich mir mal flux an, danke! Melde mich dann wieder.

    Was ich aber nicht verstehe ist, dass du trotz „inmem“ keine Probleme hast und ich mit „tsi“, was ja weniger RAM nutzen soll schon.

    Mit „tsm“ meinte ich „inmem“, dachte das sei der Begriff dafür.

  • Dann sehe ich mir mal flux an,

    Ich meinte damit nicht dass Du flux nutzen sollst. Meine Vermutung ist dass flux mehr Speicher benoetigt - also flux nicht ntzen. Aber da Du es nicht nutzt ist es ok. Ich habe es zwar bei mir installiert - aber nutze es nur in speziellen Grafanareports.

  • habe zum Test parallel das gleiche Setup auf einem Raspberry Pi 2 installiert. Hier scheint es aktuell keine Probleme zu geben.

    Werde also mal den Pi 3 neu aufsetzen.

    Ich selbst glaube nicht dran, aber stelle die Frage trotzdem einmal: Kann es an der Speicherkarte liegen? Im Pi 3 habe ich eine 128GB große und im Pi2 nur 8 GB.

    Mehr unterschiede gibt es in den Systemen nicht abgesehen vom Modell.

  • Soo jetzt habe ich vmtl. die Lösung gefunden!

    Ich habe mir mal die Kardinalität der Datenbank angesehen und war über deren Höhe sehr verwundert...

    Zitat

    Database Path: piStats

    Cardinality (exact): 719926

    Measurement Cardinality (exact)

    Und das nach jetzt weniger als zwei Wochen.

    Habe dann nach den Tags gesucht und der Übeltäter war eine "msgid". Diese habe ich Node-Red einfach mitspeichern lassen. Dachte das schadet ja nicht. Aber da das als Tag gespeichert wurde, hat es vmtl. für jeden Messwert eine neue Spalte gegeben?

    Jetzt ist die Kardinalität auch fix (bei 12) und steigt nicht mit jeder neuen Messung. Ich werde in einer Woche nochmal berichten, bin aber äußerst zuversichtlich.

    Hier der Code Node-Red Code zum Nachvollziehen, was es versaut hat. Wie geschrieben, der fix war einfach die msgid ("identity") als Tag rauszunehmen. Man könnte sie vmtl. zu den anderen Werten dazu packen ohne die Kardinalität zu erhöhen, aber das lass ich jetzt erstmal auch sein. Kann mit der ja eh nichts anfangen.

    Code
    [
        {
            "temperature": payload.AM2301.Temperature,
            "humidity": payload.AM2301.Humidity
        },{
            "identity": _msgid
        }
    ]

    Vielen Dank für die Hilfestellungen!

Jetzt mitmachen!

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