JavaScript heap out of memory / Workaround

[murf3ry]

Hallo zusammen,

nachdem ich mehrere Stunden mich mit der Fehler Meldung "JavaScript heap out of memory" rumgeschlagen haben, möchte ich euch über einen Lösungansatz/Workaround zu diesem Fehler berichten.

Der Hintergrund
Es kann wie in meinem Fall vorkommen, dass ein Adapter dem vom System bzw. Nodejs vorgegeben Arbeitseicherspeicher überschreitet und mit dem Fehler "JavaScript heap out of memory" abbricht.

Bei mir war das der Javascript Adapter, weil dieser immer ab einer Arbeitsspeicherauslasstung von 1200MB neugestartet ist (unabhängig vom ausgeführten Skript). Mit der Version 12 besitzt Nodejs die Memory Managemant Funktion (Garbage Collection Explained) die abhägig von der aktuellen Speichersystemauslastung dem auszuführenden Node Process/Adapter Speicher freigibt und diesen limitiert. Jetzt kann es in größeren Umgebung vorkommen, das dieser Wert schnell erreicht ist.

Mit den führen Nodejs Versionen war es möglich das Speicherlimit über die System Variable (export NODE_OPTIONS=--max-old-space-size=2000) oder über den Zusatz des Parameters (--max-old-space-size=2048) zu erhöhen.
Mit der Version Nodejs 12 ist das nur begrenzt möglich.
Der Iobroker WebAdmin bietet zwar die Möglichkeit eine Arbeitspeicherlimit über den Experten Modus einzustellen (Instanzen ->Expertenmodus-> Ramlimit). Normalerweise steht dort kein Wert, was zu folge hat, dass Nodejs (GCE) die Speicherlimiterung übernimmt. Setzt man jedoch dort einen wert, so wird zwar der Parameter (--max-old-space-size=2048) bei ausführen des Adapter/Processes hinzugefüght, jedoch greif diese Anpassung nicht.

Lösung/Workaround:
man setzt den Parameter (--max-old-space-size=2048) im gesamten Iobroker hoch. Hier zu edtiert man die Systemctl Startconfig

nano /lib/systemd/system/iobroker.service

ersetzt den Eintrag

Environment="NODE=$(which node)" 

durch

Environment="NODE=/usr/bin/node --max-old-space-size=2048"

Systemctl Änderungen neu einlesen

systemctl daemon-reload

und IOBROKER neustarten

iobroker restart

Die Änderungen hat zur Folge, das der Parameter "--max-old-space-size=2048" nun auf jeden Adapter/ Process innerhalb des Iobrokers greift. Meine Vermutung ist, dass der Parameter nur dann greift, wen dieser vor und nicht nach der js Datei angegeben wird. z.B.

node /path/adapter.js --max-old-space-size=2048 <<< bewirkt nichts (über den iobroker WebAdmin)

node --max-old-space-size=2048 /path/adapter.js <<< funktioniert (über die systemctl Startconfig)

Ich hoffe es hilf den einen oder anderen weiter und evtl. den Entwicklern der WebGUI.

[OliverIO]

@murf3ry

Ich würde darauf Wetten, das es nun einfach nur länger dauert bis der Fehler wieder auftritt.
Man müsste die Skripte mal untersuchen, ob da irgendwelche unendliche rekursive funktionsaufrufe oder immer wieder neue Ereignisse definiert werden. Bspw im Rahmen von setinterval oder settimeout Funktionen. Dabei kann es leicht passieren, dass Objekte nicht aufgeräumt werden können und die garbage collection hier auch versagt

So hast du den Prozessen einfach mehr möglichen Max Speicher zur Verfügung gestellt.
Das eigentliche Problem behebst du dadurch nicht.

Ich habe schon einiges mit JavaScript gemacht und kam noch nie an die Grenzen des heap Speichers.

Gern kannst du den Code deiner Skripte hier mal posten
Oder auch selbst im Internet recherchieren.

Das Schlüsselwort für die Suche ist memoryleak
https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/

[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

[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

[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