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.
