Steigender Ram/Swap nach update auf nodejs24
-
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?
-
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?
Wenn z. B. binäre Dinge nachgeladen werden.
Ich hab z. B. gestern den ganzen Abend versucht, den ioBroker mit jemalloc zu linken, ist mir nicht gelungen.
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 -
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?
@FernetMenta said:
Welche Szenarien / Adapter kennst du denn bei iob, bei denen das nicht funktionieren würde, weil die statisch gegen glibc linken?Gegenfrage:
Wie willst du oder sonst wer sicherstellen, dass keine der gefühlten 100 Packages das tun. Oder bei irgeneinem Mini Update auf einmal tun?Wer sich tief im System auskennt und experimentierfreudig ist kann das ja dank offenem System tun. Aber es sollte 200%ig klargestellt sein, dass das nichts ist was man einfach mal so empfehlen sollte für user die nicht in den Tiefen von Linux / Binaries / Linking zuhause sind.
ioBroker tut gut daran node.js die offiziell von node ausgelieferten Versionen zu verwenden - ohne etwas zu verbiegen.
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer 'nen Kaffee spendieren will: https://paypal.me
-
Wenn z. B. binäre Dinge nachgeladen werden.
Ich hab z. B. gestern den ganzen Abend versucht, den ioBroker mit jemalloc zu linken, ist mir nicht gelungen.
Wenn z. B. binäre Dinge nachgeladen werden.
Das hast nichts mit glibc und dem Problem hier zu tun. Die meinsten Adapter laden "binäre Dinge", linken aber nicht statisch geben irgendwelche Libraries.
Ich hab z. B. gestern den ganzen Abend versucht, den ioBroker mit jemalloc zu linken, ist mir nicht gelungen.
Man solle ioBroker ja nicoht geben jemalloc linken, sonder LD_PRELOAD setzen bevor man iob startet:
Bei einer nativen Installation von iob steht das in systemd. also würde das in etwa so ausswehen:
Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
ExecStart=node <pfad zu js-controller> -
Wenn z. B. binäre Dinge nachgeladen werden.
Das hast nichts mit glibc und dem Problem hier zu tun. Die meinsten Adapter laden "binäre Dinge", linken aber nicht statisch geben irgendwelche Libraries.
Ich hab z. B. gestern den ganzen Abend versucht, den ioBroker mit jemalloc zu linken, ist mir nicht gelungen.
Man solle ioBroker ja nicoht geben jemalloc linken, sonder LD_PRELOAD setzen bevor man iob startet:
Bei einer nativen Installation von iob steht das in systemd. also würde das in etwa so ausswehen:
Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2
ExecStart=node <pfad zu js-controller>Bei einer nativen Installation von iob steht das in systemd.
Und genau das habe ich gestern versucht. Auf meinem System wurde das LD_PRELOAD eben NICHT weitervererbt und der js-controller verwendete weiterhin den Standard und nicht jemalloc.
-
@FernetMenta said:
Welche Szenarien / Adapter kennst du denn bei iob, bei denen das nicht funktionieren würde, weil die statisch gegen glibc linken?Gegenfrage:
Wie willst du oder sonst wer sicherstellen, dass keine der gefühlten 100 Packages das tun. Oder bei irgeneinem Mini Update auf einmal tun?Wer sich tief im System auskennt und experimentierfreudig ist kann das ja dank offenem System tun. Aber es sollte 200%ig klargestellt sein, dass das nichts ist was man einfach mal so empfehlen sollte für user die nicht in den Tiefen von Linux / Binaries / Linking zuhause sind.
ioBroker tut gut daran node.js die offiziell von node ausgelieferten Versionen zu verwenden - ohne etwas zu verbiegen.
ioBroker tut gut daran node.js die offiziell von node ausgelieferten Versionen zu verwenden - ohne etwas zu verbiegen.
Offensichtlich ja nicht, wie man hier sieht. Dann haben halt viele User, die der der offiziellen Empfehlung node 24 zu nutzen, verlohren.
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 Anmelden556
Online33.1k
Benutzer84.2k
Themen1.4m
Beiträge