Der neue Monatsrückblick für September 2026 ist online!

[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

[Mario64]

Auch bei mir nach Upgrade von Nodejs 22 auf Nodejs 24 erhöhter RAM-Verbrauch.
Bei Nodejs 22 - RAM: ca. 3-3.5 GB
Bei Nodejs 24 - RAM: ca. 5-7.5 GB

IOB läuft dediziert auf einem Odroid-M1 (nix Container ...).
Keine Änderungen am System nur Upgrade auf Nodejs 24.

PS: Auf meinem Testsystem das selbe. RAM geht nach oben :-(

[Skippy07]

Eine Erhöhung habe ich auch festgestellt. Von 67 % auf ca. 80 % RAM Verbrauch

Raspi 5 mit 8 GB

[obstbauer]

Hallo,
bevor ich ein eigenes Thema aufmache, wollte ich hier meine Erfahrungen zeigen: Ich habe meinen Raspi 4 (4 GB. 64bit bookworm) gestern geupdatet und danach nodejs von 20.20.2 auf 24.21.0, anschließend iob von 7.0.7 auf 7.2.2. Danach ging so gut wie nichts mehr. Der RAM scheint vollgelaufen zu sein, PI war nicht mehr erreichbar über SSH, ping ging noch und ich konnte den PI nur noch durch Kabel ziehen wieder beleben. Mit htop konnte ich kurz sehen, dass der RAM ziemlich voll ist, bis dann nichts mehr ging.
Das hatte ich 2x versucht, da ich Fehler in der Reihenfolge der Updates vermutet hatte. Es hat aber keinen Unterschied gemacht.
Jetzt bin ich den Zwischenschritt über nodejs 22.23.3 gegangen und iob 7.2.2
Das läuft aktuell stabil.
Meine Frage: War der Sprung zu groß von 20 auf 24 ? Soll ich jetzt auf v24 hoch gehen oder erst abwarten (aktuell wird ja v22 empfohlen) ?
Meine Adapter habe ich noch nicht aktualisiert, soll ich das zuerst machen? Danke!
Viele Grüße
Thomas