Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[andiko2]

Hallo zusammen,

ich habe ein reproduzierbares Problem mit InfluxDB bzw. eventuell mit dem InfluxDB-Adapter/Admin und wollte fragen, ob jemand dieses Verhalten ebenfalls kennt oder schon einmal hatte.

Mein System:

ioBroker-PC: Gigabyte J3455N-D3H
CPU: Intel Celeron J3455
RAM: 16 GB
Betriebssystem: Linux Mint 21.3
InfluxDB: v2.9.1
ioBroker InfluxDB-Adapter: v4.0.2
InfluxDB läuft lokal auf demselben Rechner unter 127.0.0.1:8086

Zum Problem:

Wenn ich unter Objekte -> Datenpunkt -> InfluxDB -> Verlaufsdaten die Verlaufsdaten eines Datenpunktes öffne, steigt der RAM-Verbrauch von influxd massiv an.

In der Verlaufsansicht ist als Zeitraum "letzten 24 Stunden" eingestellt. Trotzdem finde ich anschließend im ioBroker-Log beispielsweise folgende vom Adapter ausgeführte Query:

from(bucket: "iobroker")
|> range(start: 1999-12-31T23:00:00.000Z, stop: 2026-08-20T10:31:24.374Z)
|> filter(fn: (r) => r["_measurement"] == "0_userdata.0.System.CPU_Package_Temp")
|> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value")
|> group()
|> sort(columns:["_time"], desc: false)
|> limit(n: 500)

Die Abfrage läuft teilweise in einen Timeout:

RequestTimedOutError: Request timed out

Auffällig ist insbesondere, dass range() dabei bis 1999 zurückgeht, obwohl in der Verlaufsansicht "letzten 24 Stunden" ausgewählt ist.

Ich habe das Verhalten im Terminal beobachtet mit:

watch -n 1 'ps -o pid,%cpu,%mem,rss,etime,cmd -C influxd'

Gleichzeitig habe ich die InfluxDB-Metriken beobachtet mit:

watch -n 1 'curl -s http://127.0.0.1:8086/metrics | grep -E "qc_executing_active|qc_queueing_active|qc_memory_unused_bytes"'

Während die Verlaufsansicht geöffnet ist, steht:

qc_executing_active = 1

Das Entscheidende ist:

Auch nachdem ich die Verlaufsansicht wieder komplett geschlossen habe, bleibt qc_executing_active = 1.

Gleichzeitig steigt der Speicherverbrauch von influxd weiter an.

Bei einem Test hatte influxd zunächst etwa 1,4 GB RSS. Nachdem die Verlaufsansicht bereits geschlossen war, stieg der Verbrauch weiter auf etwa 3,6 GB RSS.

Bei anderen Versuchen stieg die gesamte RAM-Auslastung des Rechners auf über 70 bis 90 Prozent.

Erst ein Neustart von InfluxDB mit

sudo systemctl restart influxdb

beendet diesen Zustand sofort.

Direkt nach einem solchen Neustart hatte influxd beispielsweise nur noch etwa 263 MB RSS.

Gleichzeitig zeigten die Metriken:

qc_executing_active = 0
qc_queueing_active = 0

Bei einem Test fiel die gesamte RAM-Auslastung des Rechners durch den InfluxDB-Neustart von 72 Prozent auf 38 Prozent.

Ich habe testweise in /etc/influxdb/config.toml folgende Speicherbegrenzung gesetzt:

query-max-memory-bytes = 1073741824

InfluxDB startet damit problemlos. Das beschriebene Verhalten wird dadurch aber nicht verhindert.

Für mich sieht es momentan so aus, als würde beim Öffnen der Verlaufsdaten eine sehr große Flux-Abfrage angestoßen, die nach dem Schließen der Ansicht serverseitig nicht beendet wird.

Ob die Ursache im InfluxDB-Adapter, im Admin oder bei InfluxDB selbst liegt, kann ich nicht beurteilen.

Hat jemand dieses Verhalten ebenfalls beobachtet oder eine Idee, warum bei ausgewählten "letzten 24 Stunden" eine Query mit range(start: 1999...) erzeugt wird und diese nach dem Schließen der Verlaufsansicht weiterläuft?

[OliverIO]

@andiko2

Bin in influx nicht so drin, aber

• in deiner query steht ja 1999 drin
• queries werden squenziell ausgeführt, d.h. Die Filterung auf die letzten 24h wird erst ausgeführt wen die subquery ausgeführt wurde.

Also

range(start: -24h)

Bis zum aktuellen Zeitpunkt.
Wen der end Zeitpunkt beliebig in der Vergangenheit liegen soll musst du start und end selbst berechnen.

[andiko2]

Ja, range(start: -24h) wäre für meinen Anwendungsfall genau das, was ich erwarten würde.

Das Problem ist nur: Die Query habe ich nicht selbst erstellt.

Sie wird automatisch erzeugt, wenn ich in ioBroker bei einem Datenpunkt die Verlaufsdaten über die InfluxDB-Instanz öffne. Dort habe ich als Zeitraum ausdrücklich "letzten 24 Stunden" ausgewählt.

Ich kann an dieser Stelle also nicht selbst range(start: -24h) in die Query schreiben.

Genau deshalb wundert mich, dass der Adapter bzw. die Verlaufsansicht daraus eine Query mit

range(start: 1999-12-31...)

erzeugt.

Wenn die Auswahl "letzten 24 Stunden" korrekt an InfluxDB übergeben würde, hätte ich ebenfalls erwartet, dass dort sinngemäß range(start: -24h) bzw. ein entsprechender berechneter Startzeitpunkt verwendet wird.

Die Frage ist für mich daher, warum ioBroker bei der automatisch erzeugten Query trotz der Einstellung "letzten 24 Stunden" bis 1999 zurückgeht.

[OliverIO]

@andiko2

Wie gesagt, bin kein influx Spezialist.
Datenbank legen bei großen Abfragen gerne temporäre Dateien an.
Deine Datei besteht aus verschiedenen datenoperationen (group,pivot,sort). Bei großen Mengen wird sowas aus dem ram ausgelagert. Datenbanken sind nur schnell,wenn die Daten oder indizies im ram liegen und sie wissen wie man schnell auf der Festplatte zugreifen kann.
Daher haben große Datenbanksysteme immer viel ram.
Gefürchtet war früher/heute immer die sogenannten Full table scans, also die Datenbank muss wirklich alles physisch lesen.

Eine Vermutung bei dir nach Neustart: influx findet die temporären Dateien und räumt sie in einem niedrig priorisierten Prozess auf. Ggfs müsste sich das nach einer Weile normalisieren.

Optimiere deine query dann passt auch die Abfrage der Daten

Hm, hatte ich oben eigentlich schon geschrieben

Die Frage ist für mich daher, warum ioBroker bei der automatisch erzeugten Query trotz der Einstellung "letzten 24 Stunden" bis 1999 zurückgeht

Zunächst wird die query ausgeführt, die ja bis 1999 zurückgeht. Diese Daten werden dann zurückgegeben. Wenn das viele Daten sind werden die dann im Adapter nochmal verarbeitet und wahrscheinlich die meisten dort weggeschmissen, weil dort erst die letzte Filterung auf 24h durchgeführt werden.
UU hast du da temporär die große Datenmenge 2x im Speicher. Einmal influx und dann noch im iobroker.
Der influx Adapter ist nur ein Vermittler zu influx, mit ein wenig Logikverarbeitung

[andiko2]

Das mit großen Abfragen und dem hohen RAM-Bedarf kann ich grundsätzlich nachvollziehen.

Ein Punkt passt bei mir allerdings nicht ganz zu der Vermutung mit den temporären Dateien:

Solange die problematische Abfrage läuft, steigt der RAM von influxd immer weiter. Auch nachdem ich die Verlaufsansicht in ioBroker geschlossen habe, bleibt qc_executing_active auf 1 und der RAM steigt weiter.

Nach einem Neustart von InfluxDB fällt der Speicher dagegen sofort wieder auf einen normalen Wert zurück. Beim letzten Test waren es danach nur noch ca. 263 MB und qc_executing_active stand sofort auf 0.

Der entscheidende Punkt ist aber: Ich kann die Query selbst nicht optimieren.

Die Query wird automatisch von ioBroker bzw. dem InfluxDB-Adapter erzeugt, wenn ich bei einem Datenpunkt die Verlaufsdaten öffne. In dieser Ansicht habe ich "letzten 24 Stunden" ausgewählt.

Trotzdem erzeugt der Adapter eine Query mit:

range(start: 1999-12-31...)

Genau deshalb versuche ich herauszufinden, warum die automatische Abfrage diesen riesigen Zeitraum verwendet. Wenn ich die Query selbst schreiben würde, wäre range(start: -24h) natürlich die naheliegende Lösung.

[OliverIO]

@andiko2

Hm wenn du die query nicht selbst erstellt hast, dann musst du ggfs ein issue auf github beim influx Adapter erstellen.

[Marc Berg]

Der Fehler kommt aus dem Admin Adapter und ist hiermit kommentiert:

// this is a code that makes problems. It is no good idea doing this!

Hintergrund ist, dass zunächst der allererste Wert ermittelt werden soll, um eine saubere Darstellung in den Charts auch an den "Rändern" zu ermöglichen. Außerdem erfolgt auch noch eine Typprüfung mit dem Datum ab 01.01.2000 0:00 Uhr local time. Nach diesen zwei Abfragen kommt erst die eigentliche Abfrage mit den korrekten Daten.

Wenn in diesem Zeitraum zu viele Daten liegen, dann führt das zu den beschriebenen Problemen. Ein Schließen des Fensters bricht die langlaufende Query nicht ab.

An deiner Stelle würde ich mal prüfen, ob die Daten konsolidiert werden können.

[andiko2]

@Marc-Berg ok danke, dann schaue ich mir das mal in Ruhe an

[andiko2]

Bei mir trat das Problem auf, dass beim Öffnen der Verlaufsdaten eines Datenpunktes im Admin der RAM-Verbrauch massiv anstieg. In einem Fall lief der Arbeitsspeicher bis auf 99 % hoch. Teilweise reagierte InfluxDB anschließend nicht mehr sauber.

Als Ursache wurde hier bereits die Abfrage des Admin-Adapters genannt, die zunächst unter anderem den allerersten vorhandenen Wert ermittelt. Bei sehr großen Datenbeständen kann diese Abfrage offenbar entsprechend aufwendig werden. Das Schließen des Fensters beendet eine bereits laufende Query zudem nicht.

Ich habe das Problem deshalb auf der Seite der Datenhaltung entschärft.

Bisher wurden bei mir sehr viele Datenpunkte gemeinsam in einer InfluxDB-Instanz gespeichert, teilweise mit wesentlich längerer Historie, als ich tatsächlich benötige.

Ich habe die Daten jetzt auf zwei InfluxDB-Instanzen mit getrennten Buckets aufgeteilt:

influxdb.0: Kurzzeitdaten, Vorhaltezeit 3 Tage
influxdb.1: Langzeitdaten, Vorhaltezeit 3 Monate

Die große Mehrheit meiner Datenpunkte benötige ich lediglich für aktuelle Grafana-Diagramme und Analysen. Dafür reichen 3 Tage vollkommen aus. Nur ausgewählte Datenpunkte, beispielsweise bestimmte Laufbandwerte, Anwesenheitsdaten und Meross-Störungszähler, benötigen eine längere Historie und wurden deshalb auf influxdb.1 umgestellt.

Zusätzlich habe ich den alten Datenbestand im bisherigen Bucket konsequent bereinigt. Da ich die Langzeithistorie bewusst neu beginnen wollte, wurden die nicht mehr benötigten alten Daten gelöscht.

Ergebnis:

Vor der Bereinigung konnte das Öffnen der Verlaufsdaten den RAM bis auf 99 % treiben.

Nach der Aufteilung und Bereinigung habe ich gezielt mehrere Verlaufsansichten geöffnet – darunter auch genau den Datenpunkt, bei dem der RAM vorher vollgelaufen war.

Der RAM blieb dabei bei etwa 39 % und zeigte praktisch keine Reaktion mehr.

Das Laden bzw. Öffnen kann im Admin weiterhin relativ lange dauern. Die problematische Abfragelogik des Admin-Adapters ist durch diese Maßnahme schließlich nicht verändert worden. Aber der massive RAM-Anstieg ist bei mir nach der Reduzierung der abzufragenden Datenmenge nicht mehr aufgetreten.

Für mich war die entscheidende Erkenntnis daher:

Nicht jeden Influx-Datenpunkt jahrelang aufbewahren, nur weil es möglich ist. Die Daten nach tatsächlich benötigter Historienlänge aufzuteilen, hat das Problem bei mir praktisch beseitigt.

Zusätzlich habe ich mir per JavaScript eine Systemanalyse erstellt, die alle für influxdb.0 und influxdb.1 aktivierten Datenpunkte auflistet. Das war beim Aufräumen und bei der Kontrolle der Zuordnung eine große Hilfe. Besten dank an Marc Berg.