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.

// 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.

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

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.

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

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.

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.