Monatsrückblick Juli / August 2026 ist online!

[OliverIO]

@Homoran

Auch mal ins syslog schauen

Dann
Ist zwar etwas weiter hergeholt und um die Suche in einem Adapter nicht zu aufwändig werden zu lassen:
Du hast jetzt 2 Adapter abgeschaltet.
Nicht das es nur an einem liegt, sondern durch die gesamtlast.

Auch eine Idee
Wenn der history Adapter viele datenpunkte pflegen muss, hat er viele dateihandles gleichzeitig offen. Wird ja alles in einzelnen Dateien gepflegt. Auch da gibt es Obergrenzen.

Noch eine Idee
Auch der interne Bus des Systems mit dem ram CPU ssd miteinander kommuniziert hat Grenzen. Da weiß ich aber nicht wie man da nachschaut. Ist aber eher am Ende der Wahrscheinlichkeiten

Daher mal das syslog um den Absturz herum untersuchen

[Homoran]

@OliverIO danke!

Ich hab ein wenig Probleme damit es jetzt an dem aktuellen System festzumachen, da es vorher bereits auftrat.

Die history erscheint mir daher sinnvoll, da dies eigentlich mal ein test werden sollte wie lange eine SD Karte halten wird, wenn man alles per json darauf speichert.
Das Experiment ist jetzt normal geworden, weil es noch nie Probleme gab.
Einmal wurde die SD Karte zu klein 😉

In dem neuen System habe ich mir eine 256GB Sandisk extreme Pro geleistet, die doppelt so schnelle Zugriffe erlaubt.

Jetzt waren Werte seit 2021 auf der Karte.
Hier hatte ich die Vermutung dass beim Durchsuchen der zigtausend Einträge das System an seine Grenzen Stösst und habe zwei Jahre gelöscht = 30GB.
Das hat jedoch nicht geholfen. Gerade habe ich nochmal ein Jahr (2023) gelöscht was nochmal 20GB Platz schaffte.

@OliverIO sagte:

Wenn der history Adapter viele datenpunkte pflegen muss, hat er viele dateihandles gleichzeitig offen. Wird ja alles in einzelnen Dateien gepflegt. Auch da gibt es Obergrenzen.

Das geht mit meinen Beobachtungen konform was die Dynamik von load und mem betrifft.

Dann habe ich mir Gedanken gemacht, ob ich vielleicht vor dem Auftreten des Problems weitere oft ändernde Datenpunkte zusätzlich historisiert habe und nicht die anzahl, so dern die Häufigkeit beim Schreiben und Lesen jetzt zu viel ist.

Da arbeite ich gerade dran.

[paul53]

@Homoran [sagte]: diesmal über PCIe statt usb

Verlagere doch das History-Verzeichnis auf die SSD (Link).

[Homoran]

@paul53 sagte:

Verlagere doch das History-Verzeichnis auf die SSD (Link).

Danke
Denke ich auch drüber nach!
Abgesehen von dem damit verbundenen Ende des Dauerexperiments, muss mich da noch einarbeten, wie das zu machen sei.
Einfach den Pfad ändern hilft ja wohl nicht.
Da muss ich wohl die Daten erst nach z.B. /mnt/Platte/data/history verschieben

[OliverIO]

@Homoran

Evtl doch mal an eine Datenbank denken
https://github.com/ioBroker/ioBroker.history/blob/master/docs/de/README.md#history-daten-in-sql-oder-influxdb-übernehmen

Eine Datenbank geht etwas sorgsamer mit System Ressourcen um.
Der history Adapter hat ja für jeden Datenpunkt ein Verzeichnis.
Darin ist für jeden Tag eine Datei.
Bei jedem Mal einen Wert historisieren bedeutet das Datei öffnen, lesen, Daten anpassen, schreiben.
Das selbenpassiert parallel mit der states.jsonl für den aktuellen Wert.

Eine Datenbank lebt mit den gerade Interessanten hauptsächlich im Speicher. Schreiben findet dann einnwenigbzeitverzögert dann optimiert nicht pro Wert sondern gesammelt statt.

Redis geht leider nur als Ersatz für die aktuellen Daten, aber nicht für die history

[Homoran]

@OliverIO sagte:

Redis geht leider nur als Ersatz für die aktuellen Daten, aber nicht für die history

Danke!
Das wollte ich noch nachfragen.

@OliverIO sagte:

Evtl doch mal an eine Datenbank denken

Ich wollte nicht noch ein System pflegen.
Bisher lief es ja über Jahre einwandfrei.

Da muss zusätzlich noch irgendwas geändert worden sein.

Wenn nicht am ioBroker, dann ggf. In der Speicherverwaltung von RaspiOS.

@OliverIO sagte:

Daher mal das syslog um den Absturz herum untersuchen

Hatte ich ja schon
https://forum.iobroker.net/post/1352625

Der oom reaper schlägt zu
Reichen 8GB schon nicht mehr aus?

Das passiert anscheinend unmittelbar vor dem Absturz und wird wie du vermutet hast wohl nicht mehr geloggt.

Auch heute morgen
Iob war due ganze Nacht durchgelaufen, load 0-1, chart sah gut aus, das freeMem, war allerdings nahe 0. Dem hatte ich keine Bedeutung zugewiesen weil available noch gut 2GB waren.

Beim anschließenden Versuch den hochauflösenden Chart zu öffnen knallte es.

Nach Neustart war das freeMem wieder >1GB und man konnte machen was man wollte.

Irgendwas stimmt mit der Speicherverwaltung nicht

Die Summe Auslastung + frei ist immer zu hoch

[Homoran]

Die Werte unter system.host.... passen an mehreren Stellen nicht.
Da läuft man dann bei der Fehlersuche einem Phantom nach.

Z.b. freeMem
Top

Host

Wenn ich den freemem einmal aus top greppe

3. Gauge, 2. Reihe (hier sinkt der Wert tlw. in den roten Bereich

Und mir dann den geloggten Wert ansehe, der allerdings aus system.host kommt

rote Linie im ersten chart
sieht man nie den Einbruch beim memFree

[Ro75]

Gut, dann hätte ich schon fast gesagt - nutze mal Redis (deutlicher Performance-Boost und geringere CPU-Last insgesamt). ABER da dein RAM so schnell nahezu weg ist - bringt REDIS nichts. Wie groß ist SWAP? Zu RaspiOS kann ich nichts sagen da mein Hauptsystem aauf Ubuntu unterwegs ist (damals auch auf einem RPI4) umd OMV (RPI5) hat Debian drauf. Also da gibt es keine Auffälligkeiten.

Ro75.

[Homoran]

@Ro75 sagte:

nutze mal Redis (deutlicher Performance-Boost und geringere CPU-Last insgesamt

Hab ich deswegen viel früher in den images für schwachbrüstige SBC immer verwendet.

Braucht man heute nicht mehr...hieß es dann.

Auch wenn ich mich innerlich immer noch weigere das Problem in der Hardware zu suchen, wie wäre installation? (Viel zu lsnge her!)

sudo apt install redis

Oder redis-server? Oder?.?

Und dann über
iob setup custom auf r umstellen?
States und objects?

[paul53]

@Homoran [sagte]:
Beim anschließenden Versuch den hochauflösenden Chart zu öffnen knallte es.

Mit oder ohne Lüfter?
Da sicherlich auch der darzustellende Zeitraum recht groß ist (> 1 h), werden sehr viele Daten von der SD-Card gelesen (IO), die vermutlich irgendwo im RAM gepuffert werden.

[Ro75]

@Homoran musst du mal schauen wie genau die installation ist. Auf alle Fälle beides umstellen. NUR wenn dir der RAM ausgeht, wird die ggfs. Redis crashen und deine Daten, sofern Redis sie nach Konfig, noch nicht auf deinem Datenträger gespeichert hat, verloren sind. Was SWAP angeht. Da gibt es unterschiedlichste Ansichten, wie Redis. Fakt ist, bei mir hat jedes Gerät eine SWAP in der Größe 50% vom RAM. Wenn gebraucht OK, wenn nicht auch OK.

Ro75.

[Homoran]

@paul53 sagte:

ohne Lüfter?

Und

@paul53 sagte:

die vermutlich irgendwo im RAM gepuffert werden.

Da wird ja auf jeden Fall die Aggregation stattfinden

[Homoran]

Der Umzug der history auf due SSD hat erwartungsgemäß leider nicht wirklich funktioniert.

2026-08-29 09:28:04.892  - error: history.0 (10517) Cannot store file /mnt/usbplatte/archiv/backup_history/20260829/history.Messwerte.0.Stromzaehler.Summenwerte.Tagesverbrauch.json: Error: EACCES: permission denied, open '/mnt/usbplatte/archiv/backup_history/20260829/history.Messwerte.0.Stromzaehler.Summenwerte.Tagesverbrauch.json'

Da fehlen mir Grundlagen

[paul53]

@Homoran [sagte]: Der Umzug der history auf due SSD hat erwartungsgemäß leider nicht wirklich funktioniert.

Offenbar hat der user "iobroker" keine Schreibrechte auf das Verzeichnis.
Weshalb "/mnt/usbplatte/archiv/backup_history" und nicht "/mnt/usbplatte/data/history"?

@Homoran sagte in Load average am Anschlag -> Neustart:

Da fehlen mir Grundlagen

sudo chmod +w /mnt/usbplatte/data/history

erlaubt allen Usern das Schreiben in das Verzeichnis.

[Homoran]

@paul53 sagte:

Weshalb "/mnt/usbplatte/archiv/backup_history" und nicht "/mnt/usbplatte/data/history"?

Weil ich das schon alles als backup dort angelegt hatte.

...und ich bekam auch nicht als user per sftp wegen der Rechte auf /opt/iobroker/iobroker-data/ history die Ordner verdchoben und gelöscht. Da musste ich es per console mit sudo cp... machen.
Mangels wissens und Routine habe ich mir dann in beiden Verzeichnissen die gesicherten Daten von 2021 und 22 gelöscht.
Nicht wirklich schlimm, wollte das aber mit den aktuellen Daten nich auch noch riskieren.

@paul53 sagte:

sudo chmod +w /mnt/usbplatte/data/history
erlaubt allen Usern das Schreiben in das Verzeichnis.

DANKE!
Das versuch ich dann

[OliverIO]

@Homoran

Der Mount muss für den User iobroker verfügbar sein.

Mit

sudo -u iobroker bash

Kannst du mit der Konsole (am prompt steht dann iobroker, anstatt deines normalen Users) schauen ob der Mount sichtbar ist
Ansonsten dann die Rechte des Mount Verzeichnis anpassen

Wenn tatsächlich der Gesamtspei her das Problem ist, wird Redis und Datenbank das Problem uU nicht verbessern.
Beide benötigen ebenfalls RAM, was dann wiederum dem iobroker fehlt.
Wenn du noch deinen alten pi hast, könntest du die history dorthin auslagern. Bei bspw dem mysql Adapter gibst du dann nicht localhost an sondern die Adresse des anderen Geräts an.
Dann findet dorthin nur noch netzverkehr statt.

Es kommt allerdings auch darauf an wie die Adapter oder Admin optimiert sind. Letztens habe ich hier ein Bericht gelesen, was auch mit aggregation von history und influx zu tun hatte.
Da hat sich gezeigt, das versucht worden ist alle Daten (seit 1999) zu laden, obwohl nur die letzten 24h gefragt wurden.
Wenn das sehr viel ist und die aggregation selbst in JavaScript gemacht wird ist das problematisch.

https://forum.iobroker.net/topic/85203/gelöst-ram-läuft-beim-öffnen-der-verlaufsdaten-voll/7?_=1787996576164

Leider finde ich die codestelle nicht mehr um zu schauen ob der history Adapter mit beteiligt ist, evtl ist es auch schon behoben, Version dürft aber noch nicht live sein.

@marc-berg
Weißt du noch wo das war?

Zum Thema ram werte stimmen nicht
Ich vermute, der iobroker kann da auch nur die systemdienste fragen. Da der ram bedarf je Prozess in Millisekunden sich ändert, kann er nur verzögert betrachten. Bei vielen Prozessen können sich kleine Abweichungen mathematisch aufsummieren.

[Homoran]

@paul53 klappt leider auch nicht

2026-08-29 12:10:46.863  - error: history.0 (8573) Cannot store file /mnt/usbplatte/data/history/20260829/history.alias.0.Stromzaehler.Bezug_aktuell.json: Error: EACCES: permission denied, open '/mnt/usbplatte/data/history/20260829/history.alias.0.Stromzaehler.Bezug_aktuell.json'
2026-08-29 12:10:46.921  - error: history.0 (8573) Cannot store file /mnt/usbplatte/data/history/20260829/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell.json: Error: EACCES: permission denied, open '/mnt/usbplatte/data/history/20260829/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell.json'
2026-08-29 12:10:46.949  - info: history.0 (8573) Delete old history "/mnt/usbplatte/data/history/20240828/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell.json"
2026-08-29 12:10:46.950  - error: history.0 (8573) Cannot delete file "/mnt/usbplatte/data/history/20240828/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell.json": Error: EACCES: permission denied, unlink '/mnt/usbplatte/data/history/20240828/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell.json'
2026-08-29 12:10:46.956  - error: history.0 (8573) Cannot store file /mnt/usbplatte/data/history/20260829/history.Messwerte.0.Solaranlage.Momentanwerte.DC1Spannung.json: Error: EACCES: permission denied, open '/mnt/usbplatte/data/history/20260829/history.Messwerte.0.Solaranlage.Momentanwerte.DC1Spannung.json'
2026-08-29 12:10:46.994  - info: history.0 (8573) Delete old history "/mnt/usbplatte/data/history/20260826/history.Messwerte.0.Solaranlage.Momentanwerte.DC1Spannung.json"
2026-08-29 12:10:46.995  - error: history.0 (8573) Cannot delete file "/mnt/usbplatte/data/history/20260826/history.Messwerte.0.Solaranlage.Momentanwerte.DC1Spannung.json": Error: EACCES: permission denied, unlink '/mnt/usbplatte/data/history/20260826/history.Messwerte.0.Solaranlage.Momentanwerte.DC1Spannung.json'
2026-08-29 12:10:47.003  - error: history.0 (8573) Cannot store file /mnt/usbplatte/data/history/20260829/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_String1.json: Error

Erst fehler beim löschen, han dann noch chmod +x gemacht.

Hilft aber anscheinend für die Unterverzeichnisse nicht.

Eine recursive Ausführung hab ich nicht hinbekommen

[Homoran]

@oliverio
Erst mal danke für die Grundlagen!
Backitup schreibt auf den mount!
Schon beim alten pi5

EDIT:

puh@BrokerRaspi:/ $ sudo -u iobroker bash
iobroker@BrokerRaspi:/ $ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=4088272k,nr_inodes=255517,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1651184k,mode=755)
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
none on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=2585)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/credentials/systemd-journald.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,noswap)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p1 on /mnt/usbplatte type ext4 (rw,relatime,stripe=32)
/dev/mmcblk0p1 on /boot/firmware type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/credentials/getty@tty1.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,noswap)
tmpfs on /run/credentials/serial-getty@ttyAMA10.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,noswap)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=825584k,nr_inodes=206396,mode=700,uid=1000,gid=1000)
iobroker@BrokerRaspi:/ $

Der mount (/mnt/usbplatte) ist sichtbar

@OliverIO sagte:

Zum Thema ram werte stimmen nicht

Da bin ich auch weitergekommen!

Es gibt zwei Datenpunkte mit einer irreführenden Bezeichnung!

Einmal freeMem und einmal memAvailable

Beides sind anscheinend Werte für available, ermittelt über verschiedene Methoden

[paul53]

@Homoran [sagte]: Eine recursive Ausführung hab ich nicht hinbekommen

Ändere mal rekursiv den Besitzer aller Dateien in "iobroker".

sudo chown -R iobroker /mnt/usbplatte/data/history

[Homoran]

@paul53 sagte:

rekursiv

Mit großem R

Danke