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

[Tobi 1]

Nichts davon, und auch sonst nichts.

Auf dem Raspberry läuft lediglich der ioBroker.

[Thomas Braun]

@tobi-1

Schalt mal swap an.

[Tobi 1]

Swap war bis vor 3 Tagen aktiviert (mit Größe 100MB, unverändert vom default-Wert).
In einem anderen Forum hab ich jedoch gelesen dass Swap deaktivieren helfen könnte (warum auch immer).
Bring keine Verbesserung, ob on oder off.

[crunchip]

@tobi-1 sagte in JS-Controller ca. alle 12h out of memory Error:

Hat jemand einen Tipp wie man feststellen kann warum der Speicher halbwegs regelmäßig voll läuft?

Vllt mal gelegentlich mit 'top' bzw 'htop' die Prozesse beobachten
Oder einfach per Gui auf die einzelnen Adapter ein Auge werfen ob da ein unnormaler hoher Ram Verbrauch entsteht..
In einem anderen Thread war es z. B der Admin wegen Fehlkonfiguration.

[Tobi 1]

@crunchip

top bzw htop hab ich immerwieder offen.
Da hat der iobroker.js-controller meistens sowas zwischen 15 und 20% Memory Auslastung.

Den Moment in dem ioBroker abstürzt habe ich leider noch nicht visuell erwischt.

Wo kann man in der GUI die Speicherauslastung der Adapter sehen?

[Codierknecht]

@tobi-1 sagte in JS-Controller ca. alle 12h out of memory Error:

Wo kann man in der GUI die Speicherauslastung der Adapter sehen?

Bei den "Instanzen"

[Tobi 1]

@codierknecht

Das ist ja dann im Prinzip das selbe wie bei htop, nur dass es in der GUI in MB angezeigt wird und nicht in %.

Der Prozess welcher immer vom System gekillt wird ist iobroker.js-controller, aber das muss vielleicht nicht zwingend der Prozess sein der den hohen Speicherbedarf verursacht.

Ich werd dann wohl erstmal versuchen zu den typischen Absturzzeiten verstärkt drauf zu achten was da passiert. Evtl über Screen-Recording.

[mcm1957]

@tobi-1
Schau mal ob deine Backupzeiten da ev korreliert.

[crunchip]

@tobi-1 sagte in JS-Controller ca. alle 12h out of memory Error:

Der Prozess welcher immer vom System gekillt wird ist iobroker.js-controller, aber das muss vielleicht nicht zwingend der Prozess sein der den hohen Speicherbedarf verursacht.

laut deinem screen, läuft der aber schon rund 42 Stunden, allerdings dein javascript nur 10 Stunden

[Tobi 1]

@mcm1957

Hatte ich auch schon im Verdacht.
Aber da der Absturz auch Tagsüber geschieht und meine Backups nachts nach 2 uhr laufen seh ich da keinen Zusammenhang

[Tobi 1]

@crunchip

Hmm.. glaube nicht, dass das Stunden:Minuten:Sekunden sind.
Der mittlere Wert erhöht sich alle 10 Sekunden rum um 1.

Also ich logge jetzt mal den Speicherbedarf heute Nacht mit den jeweiligen PIDs mit solange bis ein Absturz kommt.
Dann poste ich das Ergebnis nochmal welche PID mit welcher Speicherauslastung zuletzt lief und welche vom System gekillt wurde.

Fakt ist, wenn ein Absturz kommt ist ioBroker kurze Zeit lang nicht erreichbar und alle Adapter starten neu.

[OliverIO]

@tobi-1

evtl liegt es an einem memory leak in einem deiner skripte.
das ist allerdings nicht leicht zu finden.
gern passiert das im javascript mit setinterval/settimeout, die nicht ordentlich beednet wurden.

ist zwar auf den browser bezogen, es gelten aber die selben regeln
https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/

[OliverIO]

@tobi-1 said in JS-Controller ca. alle 12h out of memory Error:

Also ich logge jetzt mal den Speicherbedarf

unter system.
gibt es im iobroker reichlich datenpunkte um speicher je maschine und auch je adapter mit dem history adapter aufzuzeichnen

[Tobi 1]

@oliverio

Ich hab mir ein kleines python script dazu geschrieben um losgelöst vom ioBroker zu sein.

ich verwende tatsächlich in manchen Scripts setinterval, jedoch nicht erst seit kurzem.
Und die letzten Monate wenn nicht sogar schon Jahre gabs da nie Probleme… das verwundert mich etwas.

[OliverIO]

@tobi-1

wenn speicherverbrauch ansteigend ist, aber du nicht immer mehr daten in irgendwelchen objektstrukturen speicherst, dann ist es ein memory leak
dann hat bisher der speicher immer noch gereicht oder du hast es aus anderen gründen nicht wahr genommen.
wenn es ein generelles problem wäre, dann würden hier ganz viele schreiben.

[Tobi 1]

@oliverio

Ich gehe davon aus, dass es kein generelles Thema ist.
Aber ich hab auch keine Idee wie man das Problem finden kann.
Werde mir deinen Link oben noch anschauen und alle meine Scripte die einen Intervall drin haben mal deaktivieren und schauen ob es immernoch passiert.

Hatte die Hoffnung jemand kennt noch einen Kniff in ioBroker um das zu diagnostizieren

[saeft_2003]

jetzt nicht falsch verstehen, sind aber nicht 34 aktive Instanzen für 4GB RAM mehr als sportlich?

[crunchip]

@saeft_2003 seh ich auch so, wobei es auch auf die jeweiligen Adapter ankommt.
Laut screen werden aber schon rund 800MB allein durch Controller und Javascript belegt.

[Ein ehemaliger Benutzer]

@tobi-1

ich wuerde an deiner Stelle mal den javascript-Adapter stoppen, und die Kiste laufen lassen, wenn es dann stabil ist, liegts an einem Script.
Natuerlich ist 4GB auch nicht gerade viel und schnell ausgelastet, gerade bei 34 Instanzen, wenn du da noch eine VIS hast, ist schnell der Speicher voll.

Hilft nur, der Reihe nach abschalten, beobachten.

[Tobi 1]

Ja ich vermute fast auch, dass die 4GB RAM grenzwertig sind mittlerweile.

Habe das heute nacht mal mitgeloggt und auch mit dem Befehl sudo journalctl -xe nochmal geschaut.
Aber nichts auffälliges, der Speicherbedarf schwankt nicht sehr viel, aber wenn die großen Adapter gleichzeitig mehr benötigen wirds eng.

Ein massiver Anstieg eines bestimmten Adapters konnte ich nicht sehen, trotzdem gabs dann wieder den „gewohnten“ Absturz heute Nacht.

Werde mal ein paar größere Scripte deaktivieren und schauen ob es dann besser wird.
Vermutlich wirds aber eher Zeit für einen 8GB RAM Pi.