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

[murf3ry]

Hallo @oliverio

danke für deinen Hinweis. Ich werde meine Skripte anhand deines Artikel nochmal überprüfen. Meine Vermutung war Anfangs auch, dass eventuell ein Loop/Logik Fehler die Ursache dafür war. Normalerweise kann
ich relativ schnell debuggen ob es Fehler gibt. Diesmal war es nicht so, vor allem weil die Skripte schon seit mehreren Monaten gut lief bzw. wieder seit 2 Tagen wieder läuft.

Ich habe aktuell 17000 Objekte und eine 450MB großen Redis Datenbank. Somit lädt meine Javascript Instanz alle Datenpunkte in den Arbeitsspeicher und verbraucht ohne ein einziges Skript zu starten mindestens 450MB Arbeitsspeicher.
Mit wachsender Datenstruktur werden die Javascript Instanzen zwangsläufig auch größer und bringt einen schneller an das Limit. Das Limit hängt auch immer davon ab, wie stark man das System ausreizt. Zudem kommt bei mir dazu, dass ich alle Schaltvorgänge aller meiner ca. 80 Geräte über Javascript ordne, vereinheitliche und über Queues sequentiell schalte um Funk-Eskalationen (besonders interessant bei 433MHZ etc.) zu vermeiden.

Unabhängig von meinem Skript, konnte ich nachvollziehbar, dass die Iobroker WebAdmin Ramlimits nicht funktionieren und ggf. andere auch bescheid wissen sollten.

[OliverIO]

@murf3ry sagte in JavaScript heap out of memory / Workaround:

Ich habe aktuell 17000 Objekte

Warum sollte der javascript adapter den alle Objekte in den Speicher laden?
Die sind doch alle im redis-Prozess bereits im Speicher, damit schnell abgefragt werden kann.
Mach der javascript-Adapter das bei dir automatisch oder
lädst du die selber?
Bei ersterem wäre es wahrscheinlich ein Fall um das im Adapter zu optimieren. Bei zweiterem die Frage warum und müssen es alle sein.

Aber ich sehe das du dich mit JS ganz gut auskennst und im Griff hast.
ggfs. hilft es auch mal ein Profiling drüber laufen zu lassen um zu sehen,
wo ggfs ein über die Zeit anwachsender RAM-Verbrauch tatsächlich entsteht.
Ob und wie das im Detail mit dem javascript-Adapter funktioniert hab ich selbst nicht ausprobiert, aber theoretisch müsste es so wie das debugging eines adapters in den chrome dev tools erfolgen.
vgl Abschnitt 2 im folgenden Link
https://developer.ibm.com/languages/node-js/tutorials/learn-nodejs-debugging-and-profiling-node-applications/

Im google chrome kann man dann das dev-Fenster für diesen Prozess über chrome://inspect aufrufen.
Falls iobroker remote läuft, dann schreib nochmal, dann such ich dir die Parameter dafür raus.

[paul53]

@oliverio sagte: Warum sollte der javascript adapter den alle Objekte in den Speicher laden?

Damit die synchronen Versionen von getState(id), getObject(id), ... funktionieren, die auf die Puffer der Javascript-Instanz zugreifen.

[OliverIO]

hm, aber redis liegt doch schon im RAM.
Warum dann nochmal im JS-Aapter.
Wenn synchroner Abruf notwendig ist, dann halt mit await.
Kann man das konfigurieren, wenn man das nicht möchte?

[paul53]

@oliverio sagte: hm, aber redis liegt doch schon im RAM.
Warum dann nochmal im JS-Aapter.

Sogar noch im js-controller und im Admin.

@oliverio sagte in JavaScript heap out of memory / Workaround:

Kann man das konfigurieren, wenn man das nicht möchte?

In der Konfiguration der Javascript-Instanz: Haken bei "Nicht alle Zustände beim Start abonnieren". Viel Spaß damit.

[murf3ry]

Hi @oliverio

im JS Adapter selbst, gibt es die Möglichkeit nicht gleich alle State mit zuladen, jedoch habe ich damit keinen guten Erfahrungen gemacht.

Besonders spannend ist, dass man das ganze etwas schmaler machen kann, indem man den CompactModus nutzt.
Interessant ist es für mehrere Javascript Instanzen, die zu einem einzigen Prozess werden und somit den Arbeitsspeicher teilen. Das Problem ist das man hier schneller ans Nodejs Memory Limit kommt.
Mit der oben genannten Workaround sollte es evtl. funktionieren.

Ich selber nutze diesen Modus jedoch nicht, da ich noch ausreichend Speicher habe (6 von 8GB in Verwendung ) und mir vorstellen kann, dass mit der Multihost Funktionalität man hier eingeschränkter ist.
Trotzdem ist die Standardeinstellung von Nodejs12 der Meinung mich einschränken zu wollen :angry:

[Berchemer]

@paul53 sagte in JavaScript heap out of memory / Workaround:

@oliverio sagte: hm, aber redis liegt doch schon im RAM.
Warum dann nochmal im JS-Aapter.

Sogar noch im js-controller und im Admin.

@oliverio sagte in JavaScript heap out of memory / Workaround:

Kann man das konfigurieren, wenn man das nicht möchte?

In der Konfiguration der Javascript-Instanz: Haken bei "Nicht alle Zustände beim Start abonnieren". Viel Spaß damit.

Sorry, dass ich auf ein älteres Thema antworte, aber Du magst (nachvollziehbar) keinen Chat und ich schlage mich auch mit RAM-Problemen im Zusammenhang mit dem JavaScript-Adapter, bzw. wahrscheinlich verursacht durch meine Skripte, herum und wollte das mit der EInstellung Nicht alle Zustände beim Start abonnieren mal ausprobieren.

Kann es sein, dass Du das Viel Spaß damit ironisch gemeint hast???

Ich bekomme beim Neustart massenhaft Rot im Log, wenn ich das aktiviere :-(

[paul53]

@berchemer sagte: Kann es sein, dass Du das Viel Spaß damit ironisch gemeint hast???

Ja, denn dann funktioniert die synchrone Version von getState(id) nicht und man muss immer mit der Callback-Funktion arbeiten.

[Berchemer]

@paul53 sagte in JavaScript heap out of memory / Workaround:

@berchemer sagte: Kann es sein, dass Du das Viel Spaß damit ironisch gemeint hast???

Ja, denn dann funktioniert die synchrone Version von getState(id) nicht und man muss immer mit der Callback-Funktion arbeiten.

Ok. Hab's es also mit der Ironie kapiert :astonished:

[AlCalzone]

@paul53 sagte in JavaScript heap out of memory / Workaround:

und man muss immer mit der Callback-Funktion arbeiten.

oder await getStateAsync(id), welches sich fast wie die synchrone Variante verwenden lässt :)