Monatsrückblick Juli / August 2026 ist online!

[Homoran]

Die load stieg nur auf 3.54, Die Temperatur auf 54Grad.

Da wird der Lüfter angesprungen sein

Für so unwahrscheinlich ich das halte, will ich nichts ausschließen und....

habe den Lüfter abgeklemmt.
54 Grad sind absolut untertemperieet für den Pi5, entsprechend ist auch nichts im iob diag zu throttling oder overtemperature zu sehen.

@ro75
Ich bin gespannt

[Michael Schmitt]

Hast du die Möglichkeit das ganze mal auf anderer Hardware laufen zu lassen?

[Homoran]

@Michael-Schmitt sagte:

das ganze mal auf anderer Hardware laufen zu lassen

Das IST schon die andere Hardware

[Michael Schmitt]

Ok hmm auch eine andere M.2 oder gar eine andere Anbindung ssd mit USB? Vielleicht ist ja da irgendwo der Wurm drin

[Homoran]

@Michael-Schmitt sagte:

auch eine andere M.2

Ja

@Michael-Schmitt sagte:

oder gar eine andere Anbindung ssd

Ja, diesmal über PCIe statt usb

via Flachbandkabel rechts

Und sogar ein anderes OS und eine komplette neue Installation

[arteck]

@Homoran sagemal hast du den neuen nut2 adapater laufen.. wenn ja der hat bei mir gerade auch 100% cpu sich gekrallt.

[Homoran]

@arteck sagte:

hast du den neuen nut2 adapater

Nein, den alten!
Aber bei mir krallt sich niemand die CPU

Lediglich die Load geht hoch.
Muss also I/O sein.

DANKE für die info!

Ich hab mittlerweile javascript abgestelltt, spinnt trotzdem.
Dann history, sofort Ruhe.

Da bleib ich jetzt dran.

[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