Wenn es nicht eine kritische Masse gibt, nach deren Überschreitung alles zusammenbricht ergibt das für mich keinen Sinn.

Ich logge diese Daten seit 12 Jahren auf allen bisherigen Systemen.
Seit Umzug auf den Pi5 lag die load durchgehend unter 1 (backup und install ausgenommen)

Seit 2-3 Wochen jetzt diese immensen Ausreißer.

Ich weiss dass ich mit history übertrieben habe, aber ich habe gestern 30GB! Daten aus 2021 und 2022 gelöscht.
Wenn getHistory überlastet war, hätte das IMHO schleichend beginnen und nach der Radikalkur wieder beendet sein müssen.

Skripte habe ich nocht in den letzten Wochen neu angelegt oder geändert.

Es kann aus meiner Logik eher ein Adapter- oder nodejs Update verursacht haben.

wenn ich mich recht erinnere setzt du das standard jsonl als datenbank format ein. wenn du viele datenpunkte hast und auch viel history machst, kommst du evtl an die grenzen?
evtl mal redis probieren?

Ist aber wahrscheinlich nur Zufall, gestern 14:10 war da nichts entsprechendes im log.

Hier

Habe ich mal sie counts auf max aggregiert.
Input kommt auf gut 3000, output auf 600

Das korreliert nicht (??) mit den peaks bei load.

Auch wenn es bei 15:30 so sein könnte, habe ich dort mit dem Zoom in einem flot chart gespielt, bis die load auf 4 war. Danach aufgehört und die load fing sich wieder.

Das käme meiner Theorie vom Zugriff auf die SD und hoher I/O entgegen.

@Homoran sagte:

Ich hab da noch was gefunden

2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated

Das kommt mir aber bekannt vor.

der admin hat die ratings, also die bewertungssterne der adapter gelesen
https://github.com/ioBroker/ioBroker.socket-classes/blob/aea61897afee4642784737c162760db9bcdcf4fe/src/lib/socketCommandsAdmin.ts#L267

Homoran sagte:

@OliverIO sagte:

du sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?

09:04, siehe Tabelle

@oliverio
Ich hab da noch was gefunden

2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated

Das kommt mir aber bekannt vor.

@paul53 sagte:

@Homoran sagte:
für js.1 im chart integriert

Bei Input von 4000 muss ein Adapter schnell viele DP aktualisieren.

Im Moment liegt der Wert um 1500
Ich wollte nur ausreichend Luft haben

Hab daher auch den output count auf 800 hochgesetzt

@Homoran sagte:
für js.1 im chart integriert

Bei Input von 4000 muss ein Adapter schnell viele DP aktualisieren.

@Homoran sagte:
js.0 und js.1 etwa gleiche Werte (ca.1400) haben, obwohl in js.0 keine Skripte laufen

Für beide Instanzen wird der (getrennte) Puffer synchronisiert.

@OliverIO sagte:

da könntest du mal auf input counts/output counts des javascript adapters tracken, ob das zu diesen ereignissen extrem ansteigt

Ooh, nicht korrekt gelesen

Hab nur die input counts 😞

Was mich allerdings wundert ist, dass js.0 und js.1 etwa gleiche Werte (ca.1400) haben, obwohl in js.0 keine Skripte laufen

edit:
Jetzt aber

Input counts sind 10x so hoch wie die output counts

@OliverIO sagte:

Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus

Tat ich das? sorry.
Cpu last ist ganz unten die Tabelle!

@OliverIO sagte:

du sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?

09:04, siehe Tabelle

Der chart zeigt leider durch die Aggregation nicht immer alle kurzen aber massiven Ausschläge an 😞

@OliverIO sagte:

nur eine vermutung und evtl hinweise fürs weitersuchen.

Danke, das ist genau was ich brauche!

Aber Skripte sehe ich nicht, der js-Adapter läuft ruhig.

@OliverIO sagte:

bei 9:00 stärker (leider abgeschnitten)

Müsste ich mal versuchen den "echten" Wert herauszufinden

DANKE

Edit:

also du hast 2 extreme load ereignisse ca 7:50 und ca 8:56
und 1 leichtes load ereignis bei ca 8:30/8:35

1. chart

input count

bei 7:50 lässt sich nicht abschätzen
bei 8:35 er leicht an
bei 9:00 stärker (leider abgeschnitten)

freies RAM

7:50 nicht gut lesbar
8:35 leichtes abfallen
9:00 starkes abfallen

2.chart

load

hier sieht man deutlich die starken und leichen load anstiege
bei den uhrzeiten

RAM oder CPU?

Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus, das es nur die grüne load linie betrifft, der rest zeigt den ram verbrauch der adapter

bei 8:00 siehst du einen leichten anstieg und dann ein starkes abfallen.
das müsste entweder ein neustart des javascript adapters sein oder (was ungewöhnlich wäre) der adapter gibt plötzlich eine große menge an speicher frei. ich tippe auf ersteres
admin adapter steigt der ram verbrauch stärker an und fällt dann wieder ab.
9:00 ähnliches, aber nicht so stark ausgeprägt

ich tippe erst einmal auf ein skript im javascript adapter.
entweder erzeugt es viele lese und schreibvorgänge in sehr kurzer zeit
oder events schaukeln sich auf.
entweder blockt das der admin, ich glaube da gibt es eine grenze wieviel vorgänge ein adapter innerhalb einer sekunde senden darf und startet den javascript adapter neu

du sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?

die connected/disconnected meldungen sind eigentlich harmlos. alles in iobroker kommuniziert per socket. der client (also jeder adapter oder auch visualisierungen) melden sich an und schließen die verbindung wenn bspw bei vis das tablet in den schlafmodus geht (glaube ich). ich habe ähnliche meldungen, allerdings nicht ganz so oft.

ich hatte vor einigen jahre ein ähnliches problem. da hat ein skript wegen falsch programmieren setTimeouts immer mehr zugriffe auf datenpunkte erzeugt. irgendwann ist der js-controller dann abgestürzt.

aber nur eine vermutung und evtl hinweise fürs weitersuchen.
wenn du an den skripten nichts verändert hast, kann es evtl auch durch eine höhere schreibdichte auf datenpunkte, bei denen du im javascript einen trigger darauf hast kommen. evtl durch einen neuen oder aktualisierten adapter. da könntest du mal auf input counts/output counts des javascript adapters tracken, ob das zu diesen ereignissen extrem ansteigt (und hoffen das das noch geschrieben wird bevor der iobroker abstürzt)