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.

@c3b Das System bewegt sich nicht am Rand, es hängt bereits über dem Abgrund. Mit solchen Werten ist kein stabiler Betrieb mehr möglich. Wenn ram voll und swap voll löst das Betriebssystem out of memory panic aus und schiesst dann einfach so Prozesse aus dem User Space ab. Und bitte nicht auf die Idee kommen den swap zu vergrößern. RAM erweitern müsste reichen, die CPU ist ja nicht so ausgelastet.

@iceman8080 dann sollten höchstens noch bei Neustart der influx-instanz Einträge mit influxdb als Quelle auftreten. Alles andere müsste javascript als Quelle angeben

@MartinP Um das rauszufinden, dass es eh an den OSS Metrics liegt und da viele Daten drin stehen, welche man eh nicht nutzt. Am besten nicht das Standard-Bucket für ioBroker nutzen, sondern ein separates anlegen Dadurch kann man später alles einfacher löschen, was man nicht braucht. Also die go_* Measurements. Oder im Standard-Bucket direkt eine super kurze Retention Time setzen (1 Tag). Alternativ in der Config metrics-disabled = true setzen, damit die Daten gar nicht erst gesammelt werden Hatte ich alles ausführlich im Kurs erklärt. Links https://docs.influxdata.com/influxdb/v2/reference/internals/metrics/ https://docs.influxdata.com/influxdb/v2/reference/config-options/#metrics-disabled

@Salzmicha sagte: Kann man den Token auf der Consolenebene kontrollieren. Wenn ja wie ? Nicht Konsole, aber Browser: http://<ip-adresse>:8086/api/v2/authorizations Vorher an der Gui anmelden.

[image: 1777730263150-screenshot_20260502_155543_firefox.jpg] Selbst mit der Einstellung das er über 120 werte ignoriert. Macht er mir diese Spitzen. Echt keiner ne Idee

@Kusselin InfluxDB Studio sollte bei V1 noch funktionieren. https://github.com/meverett/InfluxDBStudio?tab=readme-ov-file

Ok, danke. Mit 644 hats geklappt.

ich habe jetzt dein Script zum Löschen der überflüssigen Scraper- Datenreihen gefunden und lasse es bereits laufen. Mal sehen, ob es danach besser ist beim back von Influx. Danker erstmal für deine Hilfe.

@Marc-Berg sagte in InfluxDB 2.0 - welche Measurement löschen vom Scraper: Ja. Wildcards ("go_*") funktionieren beim Löschen nicht. Also entweder einzeln manuell löschen, oder das Script nutzen, hier müssten alle erwischt werden: Danke!

@thaistatos sagte in Blockzeit ohne Funktion bzw. falsche Funktion: ich verstehe es nicht: ok, da hab ich nicht richtig hingesehen! bei history im Objekt [image: 1770451052351-screenshot_20260207-085611_duckduckgo-resized.jpg] und in der Instanz [image: 1770451071348-screenshot_20260207-085447_duckduckgo.jpg]

@mickemup @homoran Der Adapter schreibt ohne zu mucken in die Datenbank. Egal, welche Einstellungen ich darin vornehme. Außer bei der Abweichungsprüfung Werte, die nicht auftreten können (2...). Ich vermute, die Datentypmischung boolean und Zahl hat das Problem des teilweisen Nichtschreibens verursacht. Ich hatte ja auch das Problem, den Datensatz mit dem bool und Zahl Mix zu löschen. Erst am nächsten Tag ließ er sich löschen Den Löschbefehl hatte ich mit dem Editor in eine Datei geschrieben. Fehler ausgeschlossen. Nach dem Löschen des Datensatzes trat kein Fehler mehr auf. Ich bedanke mich für eure Nervenstärke. Sich aus der Ferne da reinzudenken ist nicht einfach. Unzureichende Info meinerseits waren auch nicht hilfreich.

@teletapi sagte in InfluxDB 2.0 Measurement löschen: Läuft bei mir zwar aber die buttons für Connect Ping und Help fehlen sowie unter delete auch die Auswahl. Und läuft auch nur unter Python 12.8 unter der 13.X startet die InfluxGui nicht Ok komisch, ich habe hier mal meins hochgeladen. https://www.filemail.com/d/ndtryukjwtepbct

@Krissie777 Ich finde da keine Änderung. Bei mir bekomme ich das Repo mit den genauen Befehlen angelegt: echad@chet:~ $ sudo rm /etc/apt/sources.list.d/influx* echad@chet:~ $ sudo rm /etc/apt/keyrings/influx* rm: das Entfernen von '/etc/apt/keyrings/influx*' ist nicht möglich: Datei oder Verzeichnis nicht gefunden echad@chet:~ $ curl --silent --location -O https://repos.influxdata.com/influxdata-archive.key echad@chet:~ $ gpg --show-keys --with-fingerprint --with-colons ./influxdata-archive.key 2>&1 | grep -q '^fpr:\+24C975CBA61A024EE1B631787C3D57159FC2F927:$' && cat influxdata-archive.key | gpg --dearmor | sudo tee /usr/share/keyrings/influxdata-archive.gpg > /dev/null echad@chet:~ $ echo 'deb [signed-by=/usr/share/keyrings/influxdata-archive.gpg] https://repos.influxdata.com/debian stable main' | sudo tee /etc/apt/sources.list.d/influxdata.list deb [signed-by=/usr/share/keyrings/influxdata-archive.gpg] https://repos.influxdata.com/debian stable main echad@chet:~ $ rm influxdata-archive.key echad@chet:~ $ sudo apt update OK:1 http://deb.debian.org/debian trixie InRelease OK:2 http://deb.debian.org/debian-security trixie-security InRelease OK:3 http://deb.debian.org/debian trixie-updates InRelease OK:4 http://phoscon.de/apt/deconz generic InRelease OK:5 http://phoscon.de/apt/deconz generic-beta InRelease OK:6 https://repos.influxdata.com/debian stable InRelease OK:7 https://cli.github.com/packages stable InRelease OK:8 https://apt.grafana.com stable InRelease OK:9 http://archive.raspberrypi.com/debian trixie InRelease OK:10 https://deb.nodesource.com/node_25.x nodistro InRelease OK:11 https://repo.mosquitto.org/debian trixie InRelease OK:12 https://packages.redis.io/deb trixie InRelease Holen:13 https://pkgs.tailscale.com/stable/debian trixie InRelease OK:14 https://packagecloud.io/ookla/speedtest-cli/debian trixie InRelease Es wurden 6.582 B in 2 s geholt (3.973 B/s). Alle Pakete sind aktuell. Warnung: https://deb.nodesource.com/node_25.x/dists/nodistro/InRelease: Policy will reject signature within a year, see --audit for details echad@chet:~ $ sudo apt install influxdb2 influxdb2 influxdb2-cli influxdb2-client echad@chet:~ $ sudo apt install influxdb2

Das glaube ich noch nicht. Ein einzelner Löschbefehl dauerte teilweise Minuten. Teilweise Sekunden.

Mit deinem Link funktioniert es jetzt wieder. Vielen Dank. 👍 Gruss Mike

@obstbauer sagte in Datenausreißer löschen / Alle Werte gelöscht, Warum?: stand in mehreren Anleitungen ohne 3.... Dann sind die veraltet. 'Früher' hießen die ganzen Pakete auch 'python-XYZ'. Aber seit python 3 raus ist hat man da halt zur Unterscheidung die 3 noch eingefügt.

@Neuling sagte in iobroker kann nicht mehr in influx schreiben: beim googeln gelesen habe dass einige ihren Adapter da nicht mehr gefunden haben. Genau das 'nicht mehr finden' wird doch durch die Links vermieden.

Hier der select: [image: 1763974938404-d341299e-411b-46b2-a0e2-6bc05024e30e-grafik.png] Dieser Eintrag im log mit dem Limit etc. kommt übrigens nur für dieses eine Objekt: influxdb.0 2025-11-24 09:56:22.842 debug Removed Alias: modbus.4.holdingRegisters.4.588_battery_capacity !-> Battery Capacity influxdb.0 2025-11-24 09:56:13.123 debug Send: 43 of: 44 in: 16ms influxdb.0 2025-11-24 09:56:13.109 debug Query to execute: SELECT value from "Battery Capacity" WHERE time <= '2025-11-23T23:00:00.000Z' ORDER BY time DESC LIMIT 1;SELECT * from "Battery Capacity" WHERE time > '2025-11-23T23:00:00.000Z' AND time < '2025-11-24T08:57:00.000Z' ORDER BY time DESC LIMIT 500;SELECT value from "Battery Capacity" WHERE time >= '2025-11-24T08:57:00.000Z' LIMIT 1 influxdb.0 2025-11-24 09:56:13.107 debug modbus.4.holdingRegisters.4.588_battery_capacity17639745731070.9087331471236297 getHistory message: {"id":"modbus.4.holdingRegisters.4.588_battery_capacity","options":{"instance":"influxdb.0","start":1763938800000,"end":1763974620000,"from":true,"ack":true,"q":true,"addId":false,"aggregate":"none","returnNewestEntries":true,"user":"system.user.admin"}} influxdb.0 2025-11-24 09:56:13.107 debug Incoming message getHistory from system.adapter.admin.0 influxdb.0 2025-11-24 09:56:13.080 debug Send: 500 of: 500 in: 154ms influxdb.0 2025-11-24 09:56:12.929 debug Query to execute: SELECT value from "Battery Capacity" WHERE time <= '1999-12-31T23:00:00.000Z' ORDER BY time DESC LIMIT 1;SELECT * from "Battery Capacity" WHERE time > '1999-12-31T23:00:00.000Z' AND time < '2025-11-24T08:56:13.795Z' ORDER BY time ASC LIMIT 500;SELECT value from "Battery Capacity" WHERE time >= '2025-11-24T08:56:13.795Z' LIMIT 1 influxdb.0 2025-11-24 09:56:12.926 debug modbus.4.holdingRegisters.4.588_battery_capacity17639745729260.9845860834479072 getHistory message: {"id":"modbus.4.holdingRegisters.4.588_battery_capacity","options":{"instance":"influxdb.0","start":946681200000,"end":1763974573795,"limit":1,"from":false,"ack":false,"q":false,"addId":false,"aggregate":"none","user":"system.user.admin"}} influxdb.0 2025-11-24 09:56:12.926 debug Incoming message getHistory from system.adapter.admin.0 influxdb.0 2025-11-24 09:56:12.845 debug Incoming message features from system.adapter.admin.0 influxdb.0 2025-11-24 09:55:40.273 debug Send: 43 of: 44 in: 15ms influxdb.0 2025-11-24 09:55:40.259 debug Query to execute: SELECT value from "Battery Capacity" WHERE time <= '2025-11-23T23:00:00.000Z' ORDER BY time DESC LIMIT 1;SELECT * from "Battery Capacity" WHERE time > '2025-11-23T23:00:00.000Z' AND time < '2025-11-24T08:56:00.000Z' ORDER BY time DESC LIMIT 500;SELECT value from "Battery Capacity" WHERE time >= '2025-11-24T08:56:00.000Z' LIMIT 1 influxdb.0 2025-11-24 09:55:40.258 debug modbus.4.holdingRegisters.4.588_battery_capacity17639745402580.19325231080612948 getHistory message: {"id":"modbus.4.holdingRegisters.4.588_battery_capacity","options":{"instance":"influxdb.0","start":1763938800000,"end":1763974560000,"from":true,"ack":true,"q":true,"addId":false,"aggregate":"none","returnNewestEntries":true,"user":"system.user.admin"}} influxdb.0 2025-11-24 09:55:40.257 debug Incoming message getHistory from system.adapter.admin.0 influxdb.0 2025-11-24 09:54:40.259 debug Send: 42 of: 43 in: 17ms influxdb.0 2025-11-24 09:54:40.243 debug Query to execute: SELECT value from "Battery Capacity" WHERE time <= '2025-11-23T23:00:00.000Z' ORDER BY time DESC LIMIT 1;SELECT * from "Battery Capacity" WHERE time > '2025-11-23T23:00:00.000Z' AND time < '2025-11-24T08:55:00.000Z' ORDER BY time DESC LIMIT 500;SELECT value from "Battery Capacity" WHERE time >= '2025-11-24T08:55:00.000Z' LIMIT 1 influxdb.0 2025-11-24 09:54:40.242 debug modbus.4.holdingRegisters.4.588_battery_capacity17639744802420.4969135714440529 getHistory message: {"id":"modbus.4.holdingRegisters.4.588_battery_capacity","options":{"instance":"influxdb.0","start":1763938800000,"end":1763974500000,"from":true,"ack":true,"q":true,"addId":false,"aggregate":"none","returnNewestEntries":true,"user":"system.user.admin"}} influxdb.0 2025-11-24 09:54:40.242 debug Incoming message getHistory from system.adapter.admin.0 influxdb.0 2025-11-24 09:53:40.673 debug Send: 42 of: 43 in: 21ms influxdb.0 2025-11-24 09:53:40.653 debug Query to execute: SELECT value from "Battery Capacity" WHERE time <= '2025-11-23T23:00:00.000Z' ORDER BY time DESC LIMIT 1;SELECT * from "Battery Capacity" WHERE time > '2025-11-23T23:00:00.000Z' AND time < '2025-11-24T08:54:00.000Z' ORDER BY time DESC LIMIT 500;SELECT value from "Battery Capacity" WHERE time >= '2025-11-24T08:54:00.000Z' LIMIT 1 influxdb.0 2025-11-24 09:53:40.652 debug modbus.4.holdingRegisters.4.588_battery_capacity17639744206520.6842324958529225 getHistory message: {"id":"modbus.4.holdingRegisters.4.588_battery_capacity","options":{"instance":"influxdb.0","start":1763938800000,"end":1763974440000,"from":true,"ack":true,"q":true,"addId":false,"aggregate":"none","returnNewestEntries":true,"user":"system.user.admin"}} influxdb.0 2025-11-24 09:53:40.652 debug Incoming message getHistory from system.adapter.admin.0 influxdb.0 2025-11-24 09:52:41.288 debug Send: 42 of: 43 in: 14ms influxdb.0 2025-11-24 09:52:41.275 debug Query to execute: SELECT value from "Battery Capacity" WHERE time <= '2025-11-23T23:00:00.000Z' ORDER BY time DESC LIMIT 1;SELECT * from "Battery Capacity" WHERE time > '2025-11-23T23:00:00.000Z' AND time < '2025-11-24T08:53:00.000Z' ORDER BY time DESC LIMIT 500;SELECT value from "Battery Capacity" WHERE time >= '2025-11-24T08:53:00.000Z' LIMIT 1 influxdb.0 2025-11-24 09:52:41.274 debug modbus.4.holdingRegisters.4.588_battery_capacity17639743612740.973533320590052 getHistory message: {"id":"modbus.4.holdingRegisters.4.588_battery_capacity","options":{"instance":"influxdb.0","start":1763938800000,"end":1763974380000,"from":true,"ack":true,"q":true,"addId":false,"aggregate":"none","returnNewestEntries":true,"user":"system.user.admin"}} influxdb.0 2025-11-24 09:52:41.274 debug Incoming message getHistory from system.adapter.admin.0 influxdb.0 2025-11-24 09:51:41.462 debug Send: 42 of: 43 in: 11ms influxdb.0 2025-11-24 09:51:41.452 debug Query to execute: SELECT value from "Battery Capacity" WHERE time <= '2025-11-23T23:00:00.000Z' ORDER BY time DESC LIMIT 1;SELECT * from "Battery Capacity" WHERE time > '2025-11-23T23:00:00.000Z' AND time < '2025-11-24T08:52:00.000Z' ORDER BY time DESC LIMIT 500;SELECT value from "Battery Capacity" WHERE time >= '2025-11-24T08:52:00.000Z' LIMIT 1 influxdb.0 2025-11-24 09:51:41.451 debug modbus.4.holdingRegisters.4.588_battery_capacity17639743014510.3997624257885206 getHistory message: {"id":"modbus.4.holdingRegisters.4.588_battery_capacity","options":{"instance":"influxdb.0","start":1763938800000,"end":1763974320000,"from":true,"ack":true,"q":true,"addId":false,"aggregate":"none","returnNewestEntries":true,"user":"system.user.admin"}} influxdb.0 2025-11-24 09:51:41.451 debug Incoming message getHistory from system.adapter.admin.0 influxdb.0 2025-11-24 09:51:41.413 debug Send: 500 of: 500 in: 88ms influxdb.0 2025-11-24 09:51:41.326 debug Query to execute: SELECT value from "Battery Capacity" WHERE time <= '1999-12-31T23:00:00.000Z' ORDER BY time DESC LIMIT 1;SELECT * from "Battery Capacity" WHERE time > '1999-12-31T23:00:00.000Z' AND time < '2025-11-24T08:51:42.188Z' ORDER BY time ASC LIMIT 500;SELECT value from "Battery Capacity" WHERE time >= '2025-11-24T08:51:42.188Z' LIMIT 1 influxdb.0 2025-11-24 09:51:41.325 debug modbus.4.holdingRegisters.4.588_battery_capacity17639743013250.9753410809096223 getHistory message: {"id":"modbus.4.holdingRegisters.4.588_battery_capacity","options":{"instance":"influxdb.0","start":946681200000,"end":1763974302188,"limit":1,"from":false,"ack":false,"q":false,"addId":false,"aggregate":"none","user":"system.user.admin"}} influxdb.0 2025-11-24 09:51:41.325 debug Incoming message getHistory from system.adapter.admin.0 influxdb.0 2025-11-24 09:51:41.252 debug Incoming message features from system.adapter.admin.0 influxdb.0 2025-11-24 09:51:04.621 debug Send: 44 of: 43 in: 366ms influxdb.0 2025-11-24 09:51:04.261 debug Query to execute: SELECT value from "Battery Capacity" WHERE time <= '2025-11-23T23:00:00.000Z' ORDER BY time DESC LIMIT 1;SELECT * from "Battery Capacity" WHERE time > '2025-11-23T23:00:00.000Z' AND time < '2025-11-24T08:52:00.000Z' ORDER BY time ASC;SELECT value from "Battery Capacity" WHERE time >= '2025-11-24T08:52:00.000Z' LIMIT 1 influxdb.0 2025-11-24 09:51:04.255 debug modbus.4.holdingRegisters.4.588_battery_capacity17639742642550.8420108482029569 getHistory message: {"id":"modbus.4.holdingRegisters.4.588_battery_capacity","options":{"instance":"influxdb.0","start":1763938800000,"end":1763974320000,"from":false,"ack":false,"q":false,"addId":false,"aggregate":"minmax","returnNewestEntries":true,"user":"system.user.admin"}} influxdb.0 2025-11-24 09:51:04.249 debug Incoming message getHistory from system.adapter.admin.0