Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Stefan Falt]

@oliverio Hallo, danke für das Mitdenken.

influx ui
Werde ich tun, wenn die nächste Probleme auftreten.

Ich habe jetzt eine 2,5" Festplatte angeschlossen, da die bestellte SSD erst am Samstag kommt und ioBroker neu aufgesetzt. Das geht übrigens überraschend gut.

Damit hatte ich allerdings aber auch diese "Query timeout" probleme. Jetzt habe ich den Query Timeout von 30000ms auf 60000ms gestellt, noch geht alles gut.

Ich werde weiter berichten.

MfG
StefanFalt

[Stefan Falt]

@stefan-falt
Hallo, auch mit der neuen Installation auf der 2,5" HDD habe ich den gleichen Fehler. Das ist echt Seltsam.
Ein Typischer Fehler ist:

influxdb.0
	2024-08-13 21:49:26.683	warn	Error in query "from(bucket: "iobroker") |> range(start: 2024-08-12T19:49:00.000Z, stop: 2024-08-13T19:49:00.000Z) |> filter(fn: (r) => r["_measurement"] == "modbus.0.inputRegisters.100.842_Battery_Power_(System)") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)": RequestTimedOutError: Request timed out

Wenn ich die DB Abfrage in den Data Explorer kopiere, macht die DB genau das gleiche. Der Fehler ist also Systematiisch.
Wenn ich die Daten der letzten 3 Stunden anschauen will, klappt es manchmal. Es sieht so aus, als ob die DB unendlich langsam wäre.

Ich werde das ganze mal auf SSD installieren und dann weiterschauen ....
Gibt es noch andere beschreibungen die DB zu installieren als die von Eddy? Vielleicht ist ja in der Beschreibung ein Fehler ....

https://www.youtube.com/watch?v=abV4YRHXb5I&t=1040s

[Ro75]

@stefan-falt welche Version von influxdb läuft? Aktuell ist 2.7.9. Bei einer Vorversion gab es ein Problem 2.7.x Falls die 2.7.6 laufen sollte, könnte das

https://github.com/influxdata/influxdb/issues/25157

die Ursache sein.

Ro75

[OliverIO]

@stefan-falt

Im Zweifel immer die Beschreibung des Herstellers
https://docs.influxdata.com/influxdb/v2/install/?t=Linux

Kannst du die query evtl neu aufbauen?
Bin mit influx query nicht firm, aber auch mit sql kann mann query’s bauen die im nirwana landen. Wenn ich da sehe „pivot“ dann ist das schon aufwändig, da ja die Anzahl der Spalten erst ermittelt werden müssen.

Ich sehe auch das du als rowkey time verwendest, das erzeugt je nach datenumfang auch ne Menge rows. Versuche mal testweise die auf eine Zeitscheibe zu aggregieren, also bspw 5 Minuten. Von da kannst dich dann steigern und schauen wo die Datenbank aussteigt, falls es ein performance/speicherproblem sein sollte.

[Stefan Falt]

@ro75 said in Datenbankfehler - egal wie oft ich neu installiere:

@stefan-falt welche Version von influxdb läuft? Aktuell ist 2.7.9. Bei einer Vorversion gab es ein Problem 2.7.x Falls die 2.7.6 laufen sollte, könnte das

https://github.com/influxdata/influxdb/issues/25157
die Ursache sein.
Ro75

Hallo,
Inzwischen habe ich die Installation auf der 2,5" HDD wieder verworfen und bin wieder auf den MicroSD Speicherchip gagangen.
-> gleiche Fehler.

ioBroker@raspberrypi:~ $ influx version
Influx CLI dev (git: a79a2a1b825867421d320428538f76a4c90aa34c) build_date: 2024-04-16T14:34:26Z

ioBroker@raspberrypi:~ $ curl -sL -I localhost:8086/ping
HTTP/1.1 204 No Content
Vary: Accept-Encoding
X-Influxdb-Build: OSS
X-Influxdb-Version: v2.7.9
Date: Wed, 14 Aug 2024 19:14:49 GMT

... und die Fehler sind unverändert:

influxdb.0
	2024-08-14 21:11:07.235	warn	Error in query "from(bucket: "iobroker") |> range(start: 2024-07-31T19:11:00.000Z, stop: 2024-08-14T19:11:00.000Z) |> filter(fn: (r) => r["_measurement"] == "modbus.0.inputRegisters.100.842_Battery_Power_(System)") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)": RequestTimedOutError: Request timed out

Kann es sein, dass die Datenbank es nicht mag wenn in Zeiträumen gesucht wird, in denen keine Daten vorhanden sind? Kann ich mir aber nicht vorstellen, dann muss ja das Ergebnis "null" sein. (so war es zumindestens in einem früheren Leben auf der Oracle 10g Datenbank)

Bald kommt der 40€ 500GB SSD Stick ... Oo

[Ro75]

@stefan-falt oder einfach viel zu viele Datensätze für den Rechner. Kannst du in Erfahrung bringen, wie viele wes sind?

Ro75.

[OliverIO]

@stefan-falt

Du zeigst immer nur das Iobroker log.
Was sagt das influx log?
https://docs.influxdata.com/influxdb/v2/admin/logs/

Hast du den mal die Daten aggregiert? Das ist das ähnliche was @Ro75 auch meinte.

Wenn du es schon mit 2 Speichermedien probiert hast, wird ein 3. wahrscheinlich kein anderes Ergebnis bringen.

[Wildbill]

@stefan-falt sagte in [Datenbankfehler - egal wie oft ich neu

Kann es sein, dass die Datenbank es nicht mag wenn in Zeiträumen gesucht wird, in denen keine Daten vorhanden sind? Kann ich mir aber nicht vorstellen, dann muss ja das Ergebnis "null" sein. (so war es zumindestens in einem früheren Leben auf der Oracle 10g Datenbank)

Bald kommt der 40€ 500GB SSD Stick ... Oo

Zumindest das kann ich Dir bestätigen. Als ich noch FLOT zur Visualisierung benutzt habe, bin ich auf Geräten mit Touchscreen oder Touchpad beim Versuch, einen anderen Zeitraum einzustellen, auch schon in Bereiche gerutscht, für die es (noch) keine Daten gab. Da kam in iobroker dann auch eine ähnliche Fehlermeldung. Habe ich leider nicht mehr genau im Kopf, aber irgendwas mit range war dabei.

Gruss, Jürgen

[Stefan Falt]

@oliverio said in Datenbankfehler - egal wie oft ich neu installiere:

@stefan-falt

Du zeigst immer nur das Iobroker log.
Was sagt das influx log?
https://docs.influxdata.com/influxdb/v2/admin/logs/

Hast du den mal die Daten aggregiert? Das ist das ähnliche was @Ro75 auch meinte.

Wenn du es schon mit 2 Speichermedien probiert hast, wird ein 3. wahrscheinlich kein anderes Ergebnis bringen.

Hallo Olliver,
danke für deine Zeit.

Das Verzeichnis /var/log/influxdb/ war leer, darum habe ich das logging eingeschaltet:

root@raspberrypi:/# influxd 1>/var/log/influxdb/influxd.log
WARN[0000]log.go:228 gosnowflake.(*defaultLogger).Warn DBUS_SESSION_BUS_ADDRESS envvar looks to be not set, this can lead to runaway dbus-daemon processes. To avoid this, set envvar DBUS_SESSION_BUS_ADDRESS=$XDG_RUNTIME_DIR/bus (if it exists) or DBUS_SESSION_BUS_ADDRESS=/dev/null.
Error: listen tcp :8086: bind: address already in use
See 'influxd -h' for help
root@raspberrypi:/# DBUS_SESSION_BUS_ADDRESS=/dev/null
root@raspberrypi:/#

Dann wollte ich Daten der letzten 24 Stunden Ansehen, dass wurde aber mit dem bekannten Timeout Quittiert.

influxdb.0
	2024-08-15 13:44:18.806	warn	Error in query "from(bucket: "iobroker") |> range(start: 2024-08-14T11:44:00.000Z, stop: 2024-08-15T11:44:00.000Z) |> filter(fn: (r) => r["_measurement"] == "modbus.0.inputRegisters.100.842_Battery_Power_(System)") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)": RequestTimedOutError: Request timed out

Jetzt habe ich mal einen count gemacht und siehe da, ca. 51000 die letzten 24 Stunden. Oder? Da bin ich mich nicht ganz sicher ...

Ich würde jetzt den DB Inhalt löschen, und dann das Aufzeichnen neu starten, mit weniger Daten ...

Was muss ich denn da auswählen, damit nicht mehr so viele Daten anfallen, die Daten aber noch konsistent bleiben? Blockzeit auf 5000ms ???

Stichwort Log:
Das Log ist nach etwas rumspielen leer: "cat /var/log/influxdb/influxd.log"
Aber ich Denke wir haben das Problem gefunden -> Zu viele Datensätze. Oder?

Danke + MfG
Wolfgang

[Ro75]

@stefan-falt stelle die Blockzeit mal auf 5000. Dann werden immer noch genügend Daten geloggt. Aber, das hat keine Auswirkung auf die bisher gesammelte Datenflut und damit auf den Effekt. Das wirst du also erst nach Tagen, respektive auf deinen Zeitraum feststellen können. Also Geduld.

Ro75.

[Stefan Falt]

Danke für den Support bei der Lösungsfindung
Ro75, oliverio, Wildbill