Steigender Ram/Swap nach update auf nodejs24
-
ich werde trotzdem erstmal bei 22 bleiben. Ich hatte beim Test mit 24 zuletzt nur noch 350mb available und das ist mir zu wenig, hab auch kein Bock das mir dann das System ausgeht. Als Noob liest man dann so Sachen wie Out-Of-Memory Killer und das einem das System schrotten kann wenn das bei schreibprozessen passiert.
Ich werde aber trotzdem das ganze weiter verfolgen. Zur Not muß neue Hardware her :( (ist ja so günstig im moment) -
ich werde trotzdem erstmal bei 22 bleiben. Ich hatte beim Test mit 24 zuletzt nur noch 350mb available und das ist mir zu wenig, hab auch kein Bock das mir dann das System ausgeht. Als Noob liest man dann so Sachen wie Out-Of-Memory Killer und das einem das System schrotten kann wenn das bei schreibprozessen passiert.
Ich werde aber trotzdem das ganze weiter verfolgen. Zur Not muß neue Hardware her :( (ist ja so günstig im moment)ja, erst mal beobachten.
Wenn der oom killer zuschlägt ist das übel, weil dann befindet sich das betriebssystem in einer notsituation zu der es nicht kommen sollte.
man wird sehen, ob es tatsächlich ein einheitliches problem gibt, ob da tatsächlich in node was gefixt werden muss oder ob dein system wirklich an den grenzen ist.
es kann auch sein, das ein oder mehrere adapter dinge machen, die mit v24 stärkere Auswirkungen haben.Man muss allerdings auch sehen node24 ist jetzt auch noch nicht so neu. Die kommt im November in den maintenance mode, da werden nur noch security bugs gefixt (glaube ich, leider habe ich nirgends was gefunden was maintenance genau erklärt).
Die aktuellste Version ist schon node26. wenn in v24 schwerwiegende Probleme vorliegen würden, dann wären die schon lange entdeckt.
-
Ich habe es noch nicht weiter verfolgt, mein System ist seit dem Update aber 2x eingefroren weil RAM und swap vollgelaufen sind.
Hatte ich vorher noch nie.
Hab dem CT einfach erstmal mehr RAM gegeben.EDIT
Hab am 29.9 das Update gemacht.
Finde da sieht man schon, dass er höher ist.
-
Der Grund für das Verhalten, was wir hier beobachten ist eine Entscheidung in der V8 Engine Buffers in externen nativen Speicher auszulagern. Gute Lektüre:
https://medium.com/@dev.abdullah.muhammed/know-your-limits-node-js-memory-management-part-2-rss-buffers-and-the-off-heap-world-63bfdcff144aglibc allokiert Speicher über sogenannte Arenas in 64MB Blöcken (auf einen 64 Bit System). Auf einem System mit 4 Kernen werden für einen Prozess bis zu 32 Arenas angelegt. Bei ioBroler läuft der js-controller und jeder Adapter in einem eigenen Prozess. Das Resultat ist Speicherfragmentierung die verhindert, dass die Blöcke wieder an das OS zurückgegeben werden.
Auch gute Lektüre: https://www.context.dev/blog/preventing-memory-issues-in-node-js-sharp-a-journey
Zusammenfassung:
MALLOC_ARENA_MAX=2 (über Environment)
Wenn das noch nicht zum gewünschtem Ergebnis führt, jemalloc über LD_PRELOAD verwenden.
-
Mein produktiver PI5 mit 8GB ist jetzt etwas mehr als 24 Stunden mit scavenger_max_new_space_capacity_mb=8 gelaufen. Speicherauslastung am Anfang war ca. 50%, nach 24 Stunden ca 58%. Zum Vergleich: ohne scavenger_max_new_space_capacity_mb war er nach dieser Zeit bei ca. 80%.
Ich denke das dürfte das Niveau von node 22 sein, also definitiv eine Verbesserung.Jetzt teste ich zusätzlich noch mit MALLOC_ARENA_MAX=2
Nach Systemstart und alle Instanzen aktiv ist der Pi bei 36%.
-
Für die, die nicht einfach mehr RAM zuweisen können: Wo stellt man das wie ein?
Edit: "Mein" RAM Bedarf klettert langsam aber stetig höher.
Node-js 24 würde ich so keine Empfehlunge aussprechen. Ich beobachte mal, wie es sich weiter verhält und wechsele im Zweifel zurück auf Node-JS 22.
Den RAM musste ich erhöhen, damit ioBroker das Pakelistenupdate übersteht.
-
RAM erhöhen wird nicht unbedingt was bringen. Der Bedarf kann durch die Fragmentierung auch stetig steigen bis der OOM Killer zuschlägt.
Für die, die nicht einfach mehr RAM zuweisen können: Wo stellt man das wie ein?
Das gilt natürlich nur für Linux und Container:
MALLOC_ARENA_MAX ist eine Environmentvariable. scavenger_max_new_space_capacity_mb ein Kommandozeilenparameter für node. Je nachdem wie du iob startest, kommt es an diese Stelle. Wenn du eine native Installation hast und iob über einen systemd Service gestartet wird, dann kannst du Environment und cmd Parameter dort mit angeben. Danch: sudo systemctl daemon-reload
Jede KI dir das genau sagen.
-
Ich habe node24 schon etwa 1 Jahr laufen und konnte keine große Änderung feststellen. Es sind etwa 600MB mehr als mit node22. Wie vorher auch steigt der RAM-Bedarf nach einem Neustart langsam an und pendelt sich dann ein. Ich habe 53 Adapter installiert, 17096 Objekte und 14771 Zustände.
-
Hier mal die aktualisierten Daten
Beim iobroker/js-controller selbst gibt es keine Veränderungen
bei used/totalHeap
mit installiertem javascript und echarts Adapter steigt das rssMem bei 24 um ca. 100MB (Durchschnitt) an.
system.host.iobroker_node22.memAvailable | Werte: 1041 | Min: 48156.00 | Max: 50158.00 | Durchschnitt: 49381.63
system.host.iobroker_node22.memHeapTotal | Werte: 1055 | Min: 74.47 | Max: 299.04 | Durchschnitt: 84.49
system.host.iobroker_node22.memHeapUsed | Werte: 1040 | Min: 71.07 | Max: 228.40 | Durchschnitt: 76.08
system.host.iobroker_node22.memRss | Werte: 421 | Min: 313.85 | Max: 606.48 | Durchschnitt: 356.84
system.host.iobroker_node24.memAvailable | Werte: 1040 | Min: 47908.00 | Max: 50142.00 | Durchschnitt: 49380.91
system.host.iobroker_node24.memHeapTotal | Werte: 769 | Min: 75.09 | Max: 273.30 | Durchschnitt: 85.39
system.host.iobroker_node24.memHeapUsed | Werte: 1040 | Min: 71.80 | Max: 174.49 | Durchschnitt: 75.84
system.host.iobroker_node24.memRss | Werte: 434 | Min: 434.32 | Max: 725.84 | Durchschnitt: 463.07Zusätzlich habe ich hier auch mal noch die Werte der adapter javascript und echarts aufgezeichnet
system.adapter.javascript.0.memHeapTotal | Werte: 386 | Min: 0.00 | Max: 131.82 | Durchschnitt: 96.62
system.adapter.javascript.0.memHeapUsed | Werte: 888 | Min: 0.00 | Max: 96.71 | Durchschnitt: 89.38
system.adapter.javascript.0.memRss | Werte: 113 | Min: 0.00 | Max: 260.84 | Durchschnitt: 218.89
system.adapter.echarts.0.memHeapTotal | Werte: 391 | Min: 0.00 | Max: 104.91 | Durchschnitt: 66.88
system.adapter.echarts.0.memHeapUsed | Werte: 886 | Min: 0.00 | Max: 81.49 | Durchschnitt: 59.91
system.adapter.echarts.0.memRss | Werte: 94 | Min: 0.00 | Max: 197.03 | Durchschnitt: 154.25
system.adapter.javascript.0.memHeapTotal | Werte: 460 | Min: 0.00 | Max: 221.65 | Durchschnitt: 87.49
system.adapter.javascript.0.memHeapUsed | Werte: 968 | Min: 0.00 | Max: 87.96 | Durchschnitt: 81.36
system.adapter.javascript.0.memRss | Werte: 142 | Min: 0.00 | Max: 285.67 | Durchschnitt: 225.40
system.adapter.echarts.0.memHeapTotal | Werte: 429 | Min: 0.00 | Max: 204.78 | Durchschnitt: 67.57
system.adapter.echarts.0.memHeapUsed | Werte: 967 | Min: 0.00 | Max: 80.09 | Durchschnitt: 60.86
system.adapter.echarts.0.memRss | Werte: 144 | Min: 0.00 | Max: 216.50 | Durchschnitt: 147.45Wenn man sich hier die Durschnittswerte anschaut, gibt es nur geringe Abweichungen.
Morgen würde ich dann mal noch folgendes probieren:
- iobroker Kompaktmodus (hier werden die Adapter anstatt in separaten Prozessen nur in einem Prozess (und entsprechende Subthreads) gestartet. Soll anscheinend ca 50MB pro Adapter sparen.
Einstellbar in der Adminsicht, über den Hosts-Tab, dann Schraubenschlüssel, dann häkchen bei Compact mode/Kompakter Modus - die Speicheroptimierungssettings für Node/V8, obwohl ich da persönlich kein Fan davon bin. Aber bei jemand, dessen System an seiner Grenze angelangt ist, evtl dann doch noch was hilft.
- iobroker Kompaktmodus (hier werden die Adapter anstatt in separaten Prozessen nur in einem Prozess (und entsprechende Subthreads) gestartet. Soll anscheinend ca 50MB pro Adapter sparen.
-
das sind die Werte mit nodejs v22 und js-controller v7.2.4,
würde dann heute nochmal das gleiche anstoßen mitebenfalls nun mit v24, aber js-controller v7.2.5
v22
v24
hier noch eine direkte Gegenüberstellung
mem-history-vergleich-dauerlast-memRss.csvin Summe macht das eben bei mir dann rund 1.5 GB mehr Ram bei der Anzahl an Adaptern
-
Mein produktiver PI5 mit 8GB ist jetzt etwas mehr als 24 Stunden mit scavenger_max_new_space_capacity_mb=8 gelaufen. Speicherauslastung am Anfang war ca. 50%, nach 24 Stunden ca 58%. Zum Vergleich: ohne scavenger_max_new_space_capacity_mb war er nach dieser Zeit bei ca. 80%.
Ich denke das dürfte das Niveau von node 22 sein, also definitiv eine Verbesserung.Jetzt teste ich zusätzlich noch mit MALLOC_ARENA_MAX=2
Nach Systemstart und alle Instanzen aktiv ist der Pi bei 36%.
FernetMenta sagte:
Mein produktiver PI5 mit 8GB ist jetzt etwas mehr als 24 Stunden mit scavenger_max_new_space_capacity_mb=8 gelaufen. Speicherauslastung am Anfang war ca. 50%, nach 24 Stunden ca 58%. Zum Vergleich: ohne scavenger_max_new_space_capacity_mb war er nach dieser Zeit bei ca. 80%.
Ich denke das dürfte das Niveau von node 22 sein, also definitiv eine Verbesserung.Jetzt teste ich zusätzlich noch mit MALLOC_ARENA_MAX=2
Nach Systemstart und alle Instanzen aktiv ist der Pi bei 36%.
Mein produktiv Pi ist wieder 24h gelaufen und hat sich dann mit MALLOC_ARENA_MAX=2 bei ca. 44% Speicherauslastung eingependelt. Der Speicherbedarf wurde also deutlich reduziert, aber der Effekt, dass Speicher nicht wieder freigegeben wird, ist immer noch sichtbar. Ich beobachte dies ausschließlich beim js-controller.
Jetzt läuft mein System mit jemalloc. Beim Starten ging die Speicherauslastung auf ca 45%, ging dann aber gleich wieder zurück auf 36%. Hier sieht man schon das andere Verhalten von jemalloc.
-
-
Hi Ho.
Nachdem mein Produktivsystem mit Node 24 zweimal wegen Speicherüberlauf (einschliesslich SWAP) komplett abgeschmiert ist bin ich zurück auf Node 22. Ergebnis ist das der RAM jetzt wieder bei 35-40% Auslastung liegt.
Also alles wieder paletti :-) -
-
Hier auch noch ein Hinweis auf das Problem von nodejs selbst: https://github.com/nodejs/node/blob/main/doc/api/process.md?utm_source=chatgpt.com#a-note-on-process-memoryusage
Es wird auf einen Thread verwiesen, wo ein eventueller Umstieg auf jemalloc diskutiert wurde. Da node nicht nur auf Linux zu Hause ist, wurde das nicht gemacht, aber darauf hingewiesen, dass es auf Linux durchaus Sinn macht. Das beschreibt genau die Art Applikation, die iob ist:
In my experience the reduced heap fragmentation in long-running, multi-threaded, glibc-based Linux processes is jemalloc's greatest benefit. Native Node.js modules using the libuv threadpool and worker threads would be good examples of where it might help some users some of the time.
The ability to inject jemalloc via LD_PRELOAD on Linux already provides a runtime integration on the platform it benefits most, from which one could infer it doesn't need to live in Node.js itself. Perhaps an addition to the documentation about how to do this would be appropriate?
https://github.com/nodejs/node/issues/21973#issuecomment-505123883
@bluefox Vielleicht sollte der Linux-Installer LD_PRELOAD auf jemalloc setzen. Ich bleibe bei dieser Lösung auf meinen Systemen.
-
Hier auch noch ein Hinweis auf das Problem von nodejs selbst: https://github.com/nodejs/node/blob/main/doc/api/process.md?utm_source=chatgpt.com#a-note-on-process-memoryusage
Es wird auf einen Thread verwiesen, wo ein eventueller Umstieg auf jemalloc diskutiert wurde. Da node nicht nur auf Linux zu Hause ist, wurde das nicht gemacht, aber darauf hingewiesen, dass es auf Linux durchaus Sinn macht. Das beschreibt genau die Art Applikation, die iob ist:
In my experience the reduced heap fragmentation in long-running, multi-threaded, glibc-based Linux processes is jemalloc's greatest benefit. Native Node.js modules using the libuv threadpool and worker threads would be good examples of where it might help some users some of the time.
The ability to inject jemalloc via LD_PRELOAD on Linux already provides a runtime integration on the platform it benefits most, from which one could infer it doesn't need to live in Node.js itself. Perhaps an addition to the documentation about how to do this would be appropriate?
https://github.com/nodejs/node/issues/21973#issuecomment-505123883
@bluefox Vielleicht sollte der Linux-Installer LD_PRELOAD auf jemalloc setzen. Ich bleibe bei dieser Lösung auf meinen Systemen.
Der Grund, warum das nie auf jamalloc gebracht wurde ist wohl primäer dieser:
The reason we've never done this so far is that it introduces incompatibilities between node and add-ons.
A pointer allocated in A can't be freed from B unless A and B use the same allocator. If node is linked against jemalloc and an add-on against libc, things go boom.
Likewise, even when an add-on picks up the allocator from the node binary but is linked against a library that doesn't: boom!
That means this PR is only useful in custom builds and even then only with restrictions. The help options should mention that.
Quelle: https://github.com/nodejs/node/pull/17007
So einfach ist es also nicht. Insbesondere nicht für ein Projekt, das so 'zerklüftet' ist wie der ioBroker.
Linux-Werkzeugkasten:
https://forum.iobroker.net/topic/42952/der-kleine-iobroker-linux-werkzeugkasten
NodeJS Fixer Skript:
https://forum.iobroker.net/topic/68035/iob-node-fix-skript
iob_diag: curl -sLf -o diag.sh https://iobroker.net/diag.sh && bash diag.sh -
Der Grund, warum das nie auf jamalloc gebracht wurde ist wohl primäer dieser:
The reason we've never done this so far is that it introduces incompatibilities between node and add-ons.
A pointer allocated in A can't be freed from B unless A and B use the same allocator. If node is linked against jemalloc and an add-on against libc, things go boom.
Likewise, even when an add-on picks up the allocator from the node binary but is linked against a library that doesn't: boom!
That means this PR is only useful in custom builds and even then only with restrictions. The help options should mention that.
Quelle: https://github.com/nodejs/node/pull/17007
So einfach ist es also nicht. Insbesondere nicht für ein Projekt, das so 'zerklüftet' ist wie der ioBroker.
@FernetMenta said:
@bluefox Vielleicht sollte der Linux-Installer LD_PRELOAD auf jemalloc setzen. Ich bleibe bei dieser Lösung auf meinen Systemen.Ev. sollte iob diag solche Manipulationen (LD_PRELOAD etc) loggen damit man bei einer allfälligen Fehlersuche nicht fälchlicher Weise von einen normalen System ausgeht.
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer 'nen Kaffee spendieren will: https://paypal.me
-
@FernetMenta said:
@bluefox Vielleicht sollte der Linux-Installer LD_PRELOAD auf jemalloc setzen. Ich bleibe bei dieser Lösung auf meinen Systemen.Ev. sollte iob diag solche Manipulationen (LD_PRELOAD etc) loggen damit man bei einer allfälligen Fehlersuche nicht fälchlicher Weise von einen normalen System ausgeht.
Ev. sollte iob diag solche Manipulationen (LD_PRELOAD etc) loggen damit man bei einer allfälligen Fehlersuche nicht fälchlicher Weise von einen normalen System ausgeht.
Da gibt es nur mehrere Möglichkeiten das zu versuchem dem nodejs mitzugeben. (Von denen übrigens auf meinem Testsystem keine richtig funktioniert hat).
Aber ob der js-controller mit jemalloc gelinkt ist kann man überprüfen.
Als Notiz an mich:NEW_PID=$(pgrep -f "iobroker.js-controller") sudo cat /proc/$NEW_PID/maps | grep jemalloc -
-
Der Grund, warum das nie auf jamalloc gebracht wurde ist wohl primäer dieser:
The reason we've never done this so far is that it introduces incompatibilities between node and add-ons.
A pointer allocated in A can't be freed from B unless A and B use the same allocator. If node is linked against jemalloc and an add-on against libc, things go boom.
Likewise, even when an add-on picks up the allocator from the node binary but is linked against a library that doesn't: boom!
That means this PR is only useful in custom builds and even then only with restrictions. The help options should mention that.
Quelle: https://github.com/nodejs/node/pull/17007
So einfach ist es also nicht. Insbesondere nicht für ein Projekt, das so 'zerklüftet' ist wie der ioBroker.
So einfach ist es also nicht. Insbesondere nicht für ein Projekt, das so 'zerklüftet' ist wie der ioBroker.
Welche Szenarien / Adapter kennst du denn bei iob, bei denen das nicht funktionieren würde, weil die statisch gegen glibc linken?
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 Anmelden490
Online33.1k
Benutzer84.2k
Themen1.4m
Beiträge