Monatsrückblick Oktober 2026 ist online!

[David G.]

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.

[FernetMenta]

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-63bfdcff144a

glibc 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.

[FernetMenta]

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%.

[peterfido]

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.

[FernetMenta]

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.

[Dr. Bakterius]

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.

[OliverIO]

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.07

Zusä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.45

Wenn 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.

[crunchip]

das sind die Werte mit nodejs v22 und js-controller v7.2.4, würde dann heute nochmal das gleiche anstoßen mit ebenfalls nun mit v24, aber js-controller v7.2.5
v22

v24

hier noch eine direkte Gegenüberstellung

mem-history-vergleich-dauerlast-memRss.csv

in Summe macht das eben bei mir dann rund 1.5 GB mehr Ram bei der Anzahl an Adaptern

[FernetMenta]

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.

[Mario64]

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 :-)

[rscsb]

@Mario64 sagte:

Nachdem mein Produktivsystem mit Node 24 zweimal wegen Speicherüberlauf (einschliesslich SWAP) komplett abgeschmiert ist

Hi,

wieviel RAM hast Du und wieviel Swap konfiguriert?

[MartinP]

Wenn ich das so lese, werde ich mir wohl vorerst alle manuellen Handgriffe verkneifen, node.JS auf 24 zu bringen

[FernetMenta]

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.

[Thomas Braun]

@FernetMenta

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.

[mcm1957]

@Thomas-Braun

@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.

[Thomas Braun]

@mcm1957 sagte:

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

[Mario64]

@rscsb Ich habe 8 GB RAM und 4 GB Swap. IOB läuft nativ auf einem "Odroid M1" mit Debian 13 (Trixie).

[FernetMenta]

@Thomas-Braun sagte:

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?

[Thomas Braun]

@FernetMenta

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.

[mcm1957]

@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.