Steigender Ram/Swap nach update auf nodesjs24
-
Habe mein Problem mit der Claude KI untersucht und durch wechsel auf node 22 behoben.
KI Antwort:
Nach dem Wechsel auf Node 24 hatte ich massive RAM-Probleme bis hin zu OOM-Kills. Mit einem A/B-Vergleich konnte ich es eingrenzen, vielleicht hilft das anderen.System: Raspberry Pi 5 (8 GB, NVMe), Docker mit dem offiziellen buanet-Image v11.1.0,
mem_limit4 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
latestbrachte 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 Startschleife:Memory cgroup out of memory: Killed process … (iobroker.js-con) … anon-rss:1874176kBNODE_OPTIONS="--max-semi-space-size=16"plusMALLOC_ARENA_MAX=2haben nicht geholfen, js-controller lag beim Start trotzdem bei ~1,9 GB.A/B-Vergleich (gleiches Volume, gleiche Adapter, nur anderer Image-Build):
Node 24.21.0 Node 22.23.2 Container, Spitze beim Start ~5 GB 2,5 GB Container nach ~10 min 3,7–4,2 GB 2,2 GB js-controller memRss ~2.060 MB 583 MB (nach 20 min ~410 MB) js-controller memHeapTotal ~345 MB ~388 MB Der Unterschied liegt fast komplett außerhalb des JS-Heaps.
Mögliche Ursache: https://github.com/nodejs/node/issues/61967
Mit V8 13.6 (ab Node 24) werden kurzlebige Buffer erst per Mark-Compact statt per Scavenge freigegeben. Das Issue misst Durchsatz, nicht RAM, der Mechanismus würde aber zu js-controller als DB-Server passen. Der dort genannte Workaround--scavenger-max-new-space-capacity-mb=8ist inNODE_OPTIONSnicht erlaubt, Node startet dann gar nicht.Workaround für Docker: Auf ein festes Build-Tag mit Node 22 pinnen:
image: buanet/iobroker:v11.1.0-build.20260920.013345 # Node 22.23.2Die Node-Version eines Tags lässt sich vorher prüfen (der Build 20260924 hat schon Node 24):
docker run --rm --entrypoint node buanet/iobroker:v11.1.0-build.20260920.013345 -vNach dem Wechsel liefen alle Instanzen ohne Rebuild-Fehler.
Selbst prüfen: In
system.host.<name>den WertmemRssmitmemHeapTotalvergleichen. Ist RSS unter Node 24 ein Vielfaches davon, ist man wahrscheinlich betroffen.Fragen:
- Kann das jemand bestätigen, auch bei nativer Installation? Gibt es schon ein Issue bei js-controller?
- Mag jemand mit nativer Installation testen, ob js-controller mit
--scavenger-max-new-space-capacity-mb=8direkt amnode-Aufruf wieder normal läuft?
-
Habe mein Problem mit der Claude KI untersucht und durch wechsel auf node 22 behoben.
KI Antwort:
Nach dem Wechsel auf Node 24 hatte ich massive RAM-Probleme bis hin zu OOM-Kills. Mit einem A/B-Vergleich konnte ich es eingrenzen, vielleicht hilft das anderen.System: Raspberry Pi 5 (8 GB, NVMe), Docker mit dem offiziellen buanet-Image v11.1.0,
mem_limit4 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
latestbrachte 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 Startschleife:Memory cgroup out of memory: Killed process … (iobroker.js-con) … anon-rss:1874176kBNODE_OPTIONS="--max-semi-space-size=16"plusMALLOC_ARENA_MAX=2haben nicht geholfen, js-controller lag beim Start trotzdem bei ~1,9 GB.A/B-Vergleich (gleiches Volume, gleiche Adapter, nur anderer Image-Build):
Node 24.21.0 Node 22.23.2 Container, Spitze beim Start ~5 GB 2,5 GB Container nach ~10 min 3,7–4,2 GB 2,2 GB js-controller memRss ~2.060 MB 583 MB (nach 20 min ~410 MB) js-controller memHeapTotal ~345 MB ~388 MB Der Unterschied liegt fast komplett außerhalb des JS-Heaps.
Mögliche Ursache: https://github.com/nodejs/node/issues/61967
Mit V8 13.6 (ab Node 24) werden kurzlebige Buffer erst per Mark-Compact statt per Scavenge freigegeben. Das Issue misst Durchsatz, nicht RAM, der Mechanismus würde aber zu js-controller als DB-Server passen. Der dort genannte Workaround--scavenger-max-new-space-capacity-mb=8ist inNODE_OPTIONSnicht erlaubt, Node startet dann gar nicht.Workaround für Docker: Auf ein festes Build-Tag mit Node 22 pinnen:
image: buanet/iobroker:v11.1.0-build.20260920.013345 # Node 22.23.2Die Node-Version eines Tags lässt sich vorher prüfen (der Build 20260924 hat schon Node 24):
docker run --rm --entrypoint node buanet/iobroker:v11.1.0-build.20260920.013345 -vNach dem Wechsel liefen alle Instanzen ohne Rebuild-Fehler.
Selbst prüfen: In
system.host.<name>den WertmemRssmitmemHeapTotalvergleichen. Ist RSS unter Node 24 ein Vielfaches davon, ist man wahrscheinlich betroffen.Fragen:
- Kann das jemand bestätigen, auch bei nativer Installation? Gibt es schon ein Issue bei js-controller?
- Mag jemand mit nativer Installation testen, ob js-controller mit
--scavenger-max-new-space-capacity-mb=8direkt amnode-Aufruf wieder normal läuft?
@jippsydigger [sagte]: Kann das jemand bestätigen, auch bei nativer Installation?
Kann das auf 2 Installationen in VM nicht bestätigen: Der Swap ist ungenutzt.
Produktive Installation mit 4 GB RAM für die VM (qemu):
-
Habe mein Problem mit der Claude KI untersucht und durch wechsel auf node 22 behoben.
KI Antwort:
Nach dem Wechsel auf Node 24 hatte ich massive RAM-Probleme bis hin zu OOM-Kills. Mit einem A/B-Vergleich konnte ich es eingrenzen, vielleicht hilft das anderen.System: Raspberry Pi 5 (8 GB, NVMe), Docker mit dem offiziellen buanet-Image v11.1.0,
mem_limit4 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
latestbrachte 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 Startschleife:Memory cgroup out of memory: Killed process … (iobroker.js-con) … anon-rss:1874176kBNODE_OPTIONS="--max-semi-space-size=16"plusMALLOC_ARENA_MAX=2haben nicht geholfen, js-controller lag beim Start trotzdem bei ~1,9 GB.A/B-Vergleich (gleiches Volume, gleiche Adapter, nur anderer Image-Build):
Node 24.21.0 Node 22.23.2 Container, Spitze beim Start ~5 GB 2,5 GB Container nach ~10 min 3,7–4,2 GB 2,2 GB js-controller memRss ~2.060 MB 583 MB (nach 20 min ~410 MB) js-controller memHeapTotal ~345 MB ~388 MB Der Unterschied liegt fast komplett außerhalb des JS-Heaps.
Mögliche Ursache: https://github.com/nodejs/node/issues/61967
Mit V8 13.6 (ab Node 24) werden kurzlebige Buffer erst per Mark-Compact statt per Scavenge freigegeben. Das Issue misst Durchsatz, nicht RAM, der Mechanismus würde aber zu js-controller als DB-Server passen. Der dort genannte Workaround--scavenger-max-new-space-capacity-mb=8ist inNODE_OPTIONSnicht erlaubt, Node startet dann gar nicht.Workaround für Docker: Auf ein festes Build-Tag mit Node 22 pinnen:
image: buanet/iobroker:v11.1.0-build.20260920.013345 # Node 22.23.2Die Node-Version eines Tags lässt sich vorher prüfen (der Build 20260924 hat schon Node 24):
docker run --rm --entrypoint node buanet/iobroker:v11.1.0-build.20260920.013345 -vNach dem Wechsel liefen alle Instanzen ohne Rebuild-Fehler.
Selbst prüfen: In
system.host.<name>den WertmemRssmitmemHeapTotalvergleichen. Ist RSS unter Node 24 ein Vielfaches davon, ist man wahrscheinlich betroffen.Fragen:
- Kann das jemand bestätigen, auch bei nativer Installation? Gibt es schon ein Issue bei js-controller?
- Mag jemand mit nativer Installation testen, ob js-controller mit
--scavenger-max-new-space-capacity-mb=8direkt amnode-Aufruf wieder normal läuft?
ohne Rebuild-Fehler.
Hab ich zwar nicht, aber warnungen, sichtbar bei Adapter Updates
Selbst prüfen: In system.host.<name> den Wert memRss mit memHeapTotal vergleichen
Muss ich mir mal ansehen, was mir generell aufgefallen ist, seit dem habe ich generell einen erhöhten RAM bzw hohe Spitzen. Warum und weshalb konnte ich aus zeitlichen Gründen noch nicht näher ausfindig machen
-
Habe mein Problem mit der Claude KI untersucht und durch wechsel auf node 22 behoben.
KI Antwort:
Nach dem Wechsel auf Node 24 hatte ich massive RAM-Probleme bis hin zu OOM-Kills. Mit einem A/B-Vergleich konnte ich es eingrenzen, vielleicht hilft das anderen.System: Raspberry Pi 5 (8 GB, NVMe), Docker mit dem offiziellen buanet-Image v11.1.0,
mem_limit4 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
latestbrachte 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 Startschleife:Memory cgroup out of memory: Killed process … (iobroker.js-con) … anon-rss:1874176kBNODE_OPTIONS="--max-semi-space-size=16"plusMALLOC_ARENA_MAX=2haben nicht geholfen, js-controller lag beim Start trotzdem bei ~1,9 GB.A/B-Vergleich (gleiches Volume, gleiche Adapter, nur anderer Image-Build):
Node 24.21.0 Node 22.23.2 Container, Spitze beim Start ~5 GB 2,5 GB Container nach ~10 min 3,7–4,2 GB 2,2 GB js-controller memRss ~2.060 MB 583 MB (nach 20 min ~410 MB) js-controller memHeapTotal ~345 MB ~388 MB Der Unterschied liegt fast komplett außerhalb des JS-Heaps.
Mögliche Ursache: https://github.com/nodejs/node/issues/61967
Mit V8 13.6 (ab Node 24) werden kurzlebige Buffer erst per Mark-Compact statt per Scavenge freigegeben. Das Issue misst Durchsatz, nicht RAM, der Mechanismus würde aber zu js-controller als DB-Server passen. Der dort genannte Workaround--scavenger-max-new-space-capacity-mb=8ist inNODE_OPTIONSnicht erlaubt, Node startet dann gar nicht.Workaround für Docker: Auf ein festes Build-Tag mit Node 22 pinnen:
image: buanet/iobroker:v11.1.0-build.20260920.013345 # Node 22.23.2Die Node-Version eines Tags lässt sich vorher prüfen (der Build 20260924 hat schon Node 24):
docker run --rm --entrypoint node buanet/iobroker:v11.1.0-build.20260920.013345 -vNach dem Wechsel liefen alle Instanzen ohne Rebuild-Fehler.
Selbst prüfen: In
system.host.<name>den WertmemRssmitmemHeapTotalvergleichen. Ist RSS unter Node 24 ein Vielfaches davon, ist man wahrscheinlich betroffen.Fragen:
- Kann das jemand bestätigen, auch bei nativer Installation? Gibt es schon ein Issue bei js-controller?
- Mag jemand mit nativer Installation testen, ob js-controller mit
--scavenger-max-new-space-capacity-mb=8direkt amnode-Aufruf wieder normal läuft?
Kann das jemand bestätigen
Nein, kann ich nicht bestätigen. Ich fahre meine ioBroker Container seit etwa Februar mit Node 24. In den langfristigen Metriken erkennt man den Umstieg von 22>24 überhaupt nicht.
Ich bin da bei @oliverio, die Ursache scheint ein spezifischer Adapter zu sein, der bei dir das Problem in Verbindung mit Node 24 auslöst.
-
Heute war der schon kurz nach dem reboot
Ist irrelevant. Da pendelt sich ein. Beobachte das mal nach 24 Stunden.
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
-
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.
-
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: 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
-
So sieht es bei mir aus
Auf meinem Testsystem
-
@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
Bitte aufzeichnen. Sagen wir mal bis 1h nach Neustart.
Idealerweise im Vergleich v22 und v24Die 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 AugenblicksaufnahmeWir müssen erst einmal die Ursache auf ein oder mehrere Prozesse/Adapter eingrenzen.
-
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)
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden237
Online33.1k
Benutzende83.9k
Themen1.4m
Beiträge