Node.js 24 ist jetzt offiziell empfohlen!

[Michael Schmitt]

@Thomas-Braun sagte:

@Michael-Schmitt sagte:

Heute war der schon kurz nach dem reboot

Ist irrelevant. Da pendelt sich ein. Beobachte das mal nach 24 Stunden.

bin nun zum testen wieder auf nodejs24 und schau mir das mal 24 std an

[jippsydigger]

Danke für die Werte!

@paul53: 391 MB memRss bei 129 MB Heap, also gut 260 MB außerhalb des Heaps. Das ist unauffällig. Bei mir waren es unter Node 24 1,75–2 GB bei 270–345 MB Heap, also rund 1,5 GB außerhalb.

@Marc-Berg: 36 MB Heap ist für einen js-controller sehr wenig. Laufen States/Objects bei dir in Redis? Dann macht dein js-controller keine DB-Arbeit. Bei mir ist er mit jsonl der DB-Server, und genau er wächst unter Node 24.

@Michael-Schmitt: Magst du nach deinen 24 h auch memRss und memHeapTotal posten? Du nutzt wie ich jsonl auf einem Raspi, hast aber ein deutlich kleineres System. Liegt der js-controller bei dir auch weit über dem Heap, spricht das eher für die Plattform als für die Systemgröße.

Meine 24-h-Werte unter Node 22 kommen morgen.

[Michael Schmitt]

@jippsydigger sagte:

@Michael-Schmitt: Magst du nach deinen 24 h auch memRss und memHeapTotal posten? Du nutzt wie ich jsonl auf einem Raspi, hast aber ein deutlich kleineres System. Liegt der js-controller bei dir auch weit über dem Heap, spricht das eher für die Plattform als für die Systemgröße.

das ist von jetzt, dann poste ich morgen mal das neue

[crunchip]

So sieht es bei mir aus

Auf meinem Testsystem

[OliverIO]

@Michael-Schmitt

Bitte aufzeichnen. Sagen wir mal bis 1h nach Neustart.
Idealerweise im Vergleich v22 und v24

Die Zahlen sind Augenblicksaufnahmen.
Wie in einem anderen Thread zu einem anderen Thema gesehen,
können die Werte innerhalb von Sekunden oder sogar kürzer stark schwanken.
Das top sieht ja eigentlich entspannt aus. ist das jetzt mit v22 oder v24?
Aber halt auch nur eine Augenblicksaufnahme

Wir müssen erst einmal die Ursache auf ein oder mehrere Prozesse/Adapter eingrenzen.

[Meister Mopper]

Ich kann einen Anwachs des RAM-Verbrauchs bei meinen Systemen nicht bestätigen. Ich habe in der letzten Woche alles auf nodejs 24 gehoben:

Trixie VM

Test LXC

raspberryPi Slave (4B, 8G)

[Michael Schmitt]

Jetzt sind es nicht ganz 24 Std

[crunchip]

@Michael-Schmitt sieht doch alles plausibel aus

[Michael Schmitt]

und da ich noch drei updates einspielen mußte hier direkt nach dem reboot.

ich werd das mal so laufen lassen und beobachten

[Marc Berg]

hier stand Unsinn

[Marc Berg]

@jippsydigger sagte:

@Marc-Berg: 36 MB Heap ist für einen js-controller sehr wenig. Laufen States/Objects bei dir in Redis? Dann macht dein js-controller keine DB-Arbeit. Bei mir ist er mit jsonl der DB-Server, und genau er wächst unter Node 24.

In der Tat hatte ich vorher eine Redis-DB im Einsatz. Habe jetzt aber mal testweise auf jsonl migriert, mit einem ähnlich entspannten Ergebnis:

[jippsydigger]

Nachtrag nach 24 Stunden, gleiches System, gleiche Adapter, nur Node getauscht:

	memRss	memHeapTotal
Node 24, nach ~24 h	1.749 MB	271 MB
Node 22, nach ~26 h	313 MB	218 MB

Unter Node 24 hat sich also nichts eingependelt.

@OliverIO: Eingegrenzt ist es auf den js-controller. Den hat der OOM-Killer unter Node 24 mehrfach beendet, der Rest des Containers ist unter beiden Versionen etwa gleich groß.

Die Plattform-These nehme ich zurück: crunchips Produktivsystem (x86, 52.000 Objekte) liegt unter Node 24 ebenfalls bei rund 1,3 GB außerhalb des Heaps. Bei paul53, Marc (jsonl) und crunchips Testsystem sind es 200–300 MB, bei Michael wächst es über den Tag von rund 420 auf 640 MB. Es scheint eher mit der Größe bzw. der DB-Last zu wachsen.

@crunchip: Hast du von deinem Produktivsystem noch memRss-Werte aus der Node-22-Zeit? Dann sieht man, ob die 1,8 GB neu sind.

@Marc-Berg: Danke fürs Gegentesten mit jsonl!

[Michael Schmitt]

keine Ahnung was mir da den Ram wegfrißt

EDIT: der js controller mit fast 40% :(

[FernetMenta]

@jippsydigger sagte:

System: Raspberry Pi 5 (8 GB, NVMe), Docker mit dem offiziellen buanet-Image v11.1.0, mem_limit 4 GB, js-controller 7.2.2, States/Objects als jsonl. 14 aktive Instanzen: admin, javascript, node-red, 3× influxdb, 2× modbus, openknx, viessmannapi (~15.000 Objekte), telegram, web, wled, energiefluss-erweitert.

Was passiert ist: Ein Re-Pull von latest brachte einen neuen Build von v11.1.0 mit Node 24.21.0 statt 22. Das Tag bleibt dabei gleich, weil die Build-Pipeline die empfohlene Node-Version erst beim Bauen einsetzt. Docker Hub führt v11.1.0 noch unter „Node 22 versions“. Danach wurde js-controller beim Start mehrfach gekillt, und der Container hing in einer

Wenn man node major updated, änder sich die ABI. Das erfordert ein npm rebuild auf die node_modules. M.W. macht das das buanet Image aber nicht eigenständig. Der js-controller hat native module die compiliert werden müssen.

[OliverIO]

@jippsydigger sagte:

Eingegrenzt ist es auf den js-controller. Den hat der OOM-Killer unter Node 24 mehrfach beendet, der Rest des Containers ist unter beiden Versionen etwa gleich groß.

leider ist das kein indiz
der oom killer berechnet für jeden prozess einen oom score, anhand dessen entschieden wird welcher prozess beendet wird.
da der js-controller bei vielen aktivitäten mit beteiligt ist, kann auch ein adapter die ursache sein. da der js-controller prozess mehr speicher benötigt, wie ein adapter prozess, hat er einen höheren score.
in dem von mir verlinkten prozess war bspw der history adapter der verursacher, da der nutzer viele diagramme in vis eingebunden hat. der history adapter hat sehr kurzzeitig (das wäre wahrscheinlich in top gar nicht sichtbar gewesen) viele threads gestartet, die jeder für sich wieder RAM benötigt. Jeder dieser Sub-Threads haben aber nur sehr kurz gelebt.
ich will nicht sagen, das das bei dir die ursache ist, aber wie oben schon erwähnt, einmalige screenshots mit augenblickaufnahme werden wahrscheinlich nicht die ursache offenbaren.

da einige über verlaufsdaten gezeigt haben, das ein wechsel von 22 auf 24 sogut wie keine auswirkungen hatte, könnte es bei dir auch etwas anderes sein.
leider ist jedes system, mit unterschiedlicher Anzahl und zusammensetzung von Adaptern sehr individuell. Wenn ein generelles Problem vorliegen würde, wären hier im Forum auch noch einige mehr threads dazu (gut die Umstellung auf v24 läuft auch erst gerade an)

schau mal nochmal in den verlinkten thread rein. da sind analyse scripts drin (die leider sehr große outputs erzeugen), mit dem man tiefer analysieren könnte.

aber ich würde mal immer noch auf die aufzeichnung der memory werte von adaptern verweisen (1h dürfte reichen) idealerweise im vergleich zu v22 basis.

bspw habe ich auch diesen thread gesehen, leider ohne reaktion von irgendjemanden.
matter hatte ich glaube ich bei dir auch gesehen.
https://forum.iobroker.net/topic/85474/steigender-ram-beim-matter-adapter?_=1790863527158

[crunchip]

@jippsydigger sagte:

Hast du von deinem Produktivsystem noch memRss-Werte aus der Node-22-Zeit? Dann sieht man, ob die 1,8 GB neu sind.

Müsst ich nachschauen.
Letztendlich läuft bei mir ein spezielles Script, der das System überwacht.
Und seit der Umstellung auf v24(aber auch ein paar Updates verschiedener Adapter) wurde ich in unregelmäßigen Abständen benachrichtigt das mein RAM überschritten ist.
Sa dann so aus

Eigentlich lag ich immer so bei 8-9Gb incl Spitzen

[OliverIO]

@crunchip

die veränderungen bei deinen 3 top verbrauchern ist allerdings nur sehr gering oder das gesamtsystem ist schon sehr nahe an deinen 10gb
größere veränderungen bei anderen adaptern die dann zum überschwappen führen sieht man da nicht.

[Meister Mopper]

Hm, ich muss das mal eine längere Zeitspanne beobachten.

Hier meine Werte der letzen 30 Tage. Am 27.09. habe ich die Proxmox VM (8G) und den Raspberrypi (Version B, 8G) auf nodejs 24 gebracht.

Es hat sich tatsächlich etwas getan, aber als dramatisch würde ich es nicht bezeichnen.

VM

RPI

[Michael Schmitt]

ich hab nun mal eine iob stop und iob start gemacht. Warum geht der js-controller mit der Zeit im Ram so hoch ? (Der kleinere Wert von 16,3% ist nach dem Neustart und die 39,5% davor)

[crunchip]

@OliverIO wie oben geschrieben lag ich konstant zwischen 8-9Gb incl Spitzen, also noch 1-2Gb Luft bevor die Meldung kommt, da ich mir eine Schwelle 10GB gesetzt hatte.
Allerdings:
Neuste Beobachtungen steigt auch der Admin mal auf rund 550Mb, genauso der Web Adapter, das wiederum schiebe ich allerdings darauf, daß ich den aura Adapter incl KI kürzlich eingebunden habe.
Hatte anderweitig auch schon angefangen unnötige Adapter zu deinstallieren bzw zu deaktivieren, stellt allerdings ja keine Lösung dar.

Muss mir das in Ruhe mal ansehen, Fliesen ja genug Daten in die Datenbänke

EDIT:

hier sieht man den Anstieg

anders Aufgelöst im history Adapter

sieht man seit der Umstellung ab dem 25. 09 immer 2 Spitzen, einmal Vormittags ca um 11Uhr und einmal abends gegen 23Uhr, jetzt müsste ich nur herausfinden woher das kommt

EDIT:
@jippsydigger
hab nun Testhalber buanet/iobroker:v11.1.0-build.20260902.012040 eingespielt
zu Beginn war memRss bei ca 1700, dacht ok, hat dann doch nichts damit zu tun, 8min nach Neustart hat sich das dann allerdings beruhigt und pendelt um die 1200mb, also ca 500mb weniger als mit dem latest image, zum Vergleich sieh oben https://forum.iobroker.net/post/1356937

und ebenfalls beim Testsystem ausgeführt, allerdings läuft da noch js-controller 7.2.2

EDIT:
und weil ich mir noch die Host-Basiseinstellung zwecks Objekte und Zustände angesehen habe, stellte ich fest, das ich auf meinem doch schon sehr alten Produktiv System abweichende Werte hatte, im Vergleich zum Test System, dort waren andere Faktoren und Intervalle hinterlegt. Hab diese nun mal angepasst und neu gestartet.

Aktuell sieht es so aus:
da sieht man den Abfall nach der Umstellung

EDIT:
Fazit,
nachdem sich das System nun eingependelt hat, läuft es mit nodejs 22 bei rund 8GB , die Tage zuvor mit nodejs24 lag es bei gut 9GB.
Die Frage WARUM ist dadurch allerdings noch nicht geklärt