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

[OliverIO]

In Ergänzung mal hier als Diagramme in der Sicht 18:00 bis 13:00
Wie gesagt, alles in der Standardinstallation + history Adapter (also sonst keine weiteren Adapter).
Habe gerade noch den echarts-Adapter und den javascript-Adapter installiert, was aber nicht in dieser Zeitsicht enthalten ist.
Ich werde die beiden Server mal noch bis morgen weiterlaufen lassen.
Evtl werde ich im Anschluss auch mal noch einen Vergleichstest mit ausgewählten Adaptern machen, die auch ein wenig mehr traffic auf dem iobroker erzeugt

Node 22

system.host.iobroker_node22.memAvailable | Werte: 1528 | Min: 50699.00 | Max: 51700.00 | Durchschnitt: 51509.88
system.host.iobroker_node22.memHeapTotal | Werte: 1701 | Min: 70.97 | Max: 246.29 | Durchschnitt: 79.18
system.host.iobroker_node22.memHeapUsed | Werte: 1528 | Min: 66.83 | Max: 223.33 | Durchschnitt: 71.98
system.host.iobroker_node22.memRss | Werte: 585 | Min: 234.66 | Max: 471.80 | Durchschnitt: 250.08

Node24

system.host.iobroker_node24.memAvailable | Werte: 1544 | Min: 50480.00 | Max: 51668.00 | Durchschnitt: 51509.98
system.host.iobroker_node24.memHeapTotal | Werte: 1746 | Min: 72.34 | Max: 316.88 | Durchschnitt: 78.83
system.host.iobroker_node24.memHeapUsed | Werte: 1543 | Min: 68.58 | Max: 219.19 | Durchschnitt: 73.50
system.host.iobroker_node24.memRss | Werte: 567 | Min: 248.79 | Max: 690.53 | Durchschnitt: 260.69

Man sieht an den Durchschnittswerten, das da nicht viel Unterschied ist.
Gut kann sein, das sich das aufsummiert, wenn man entsprechend viele Adapter laufen hat. Aber bei heapTotal und heapUsed sind es nur 1 stellige MB, bei rss 10MB
Die Nicht sichtbaren Max-Werte sind wahrscheinlich der Aggregation im Diagramm zum Opfer gefallen.

Hier mal noch das Skript zum nachvollziehen. Bei den Datenpunkten muss der Name der eigenen iobroker Instanz angepasst werden

Spoiler

/**
* Min / Max / Durchschnitt für mehrere Datenpunkte
* über den ioBroker History Adapter.
*/

// -----------------------------------------------------------------------------
// Konfiguration
// -----------------------------------------------------------------------------

const HISTORY_INSTANCE = 'history.0';

// Lokale Zeit
const START = '2026-10-03 18:00:00';
const END = '2026-10-04 13:00:00';

const DATA_POINTS = [
   'system.host.iobroker_node22.memAvailable',
   'system.host.iobroker_node22.memHeapTotal',
   'system.host.iobroker_node22.memHeapUsed',
   'system.host.iobroker_node22.memRss',
];

// -----------------------------------------------------------------------------
// Hilfsfunktionen
// -----------------------------------------------------------------------------

function parseLocalDate(dateString) {
   const [datePart, timePart] = dateString.split(' ');
   const [year, month, day] = datePart.split('-').map(Number);
   const [hour, minute, second] = timePart.split(':').map(Number);

   return new Date(year, month - 1, day, hour, minute, second).getTime();
}

function getStatistics(id, start, end) {
   return new Promise((resolve, reject) => {
       sendTo(
           HISTORY_INSTANCE,
           'getHistory',
           {
               id,
               options: {
                   start,
                   end,
                   aggregate: 'none',
                   addId: false,
               },
           },
           result => {
               if (result && result.error) {
                   reject(new Error(result.error));
                   return;
               }

               if (!result || !Array.isArray(result.result)) {
                   reject(new Error(`Keine gültigen History-Daten für ${id}`));
                   return;
               }

               const values = result.result
                   .map(entry => Number(entry.val))
                   .filter(value => Number.isFinite(value));

               if (values.length === 0) {
                   resolve({
                       id,
                       count: 0,
                       min: null,
                       max: null,
                       avg: null,
                   });
                   return;
               }

               const min = Math.min(...values);
               const max = Math.max(...values);
               const sum = values.reduce((total, value) => total + value, 0);

               resolve({
                   id,
                   count: values.length,
                   min,
                   max,
                   avg: sum / values.length,
               });
           },
       );
   });
}

// -----------------------------------------------------------------------------
// Auswertung
// -----------------------------------------------------------------------------

async function main() {
   const start = parseLocalDate(START);
   const end = parseLocalDate(END);

   if (start >= end) {
       log('START muss vor END liegen.', 'error');
       return;
   }

   log(`Auswertung von ${START} bis ${END}`);
   log(`History-Instanz: ${HISTORY_INSTANCE}`);

   for (const id of DATA_POINTS) {
       try {
           const result = await getStatistics(id, start, end);

           if (result.count === 0) {
               log(`${id}: Keine Werte im angegebenen Zeitraum.`, 'warn');
               continue;
           }

           log(
               `${id} | Werte: ${result.count} | ` +
               `Min: ${result.min.toFixed(2)} | ` +
               `Max: ${result.max.toFixed(2)} | ` +
               `Durchschnitt: ${result.avg.toFixed(2)}`,
           );
       } catch (error) {
           log(`Fehler bei ${id}: ${error.message}`, 'error');
       }
   }
}

main();

[Michael Schmitt]

@OliverIO sagte:

Werte: 1544 | Min: 50480.00 | Max: 51668.00

Kurze Frage, du hast über 50gb Ram ? und noch 1,54gb frei ?

[OliverIO]

@Michael-Schmitt

nein andersrum. der Datenpunkt heißt availableMem.
Der Rechner hat 64GB
Da laufen diverse Docker container darauf
Echtes frei ist tatsächlich nur 1,5GB
Tatsächlich benutzt knapp 16GB
Das ist aber nur in Verbindung mit dem kurzfristig verfügbaren Speicher zu sehen
48GB buff/cache

MiB Mem :  64047.9 total,   1599.2 free,  15915.1 used,  47891.7 buff/cache

Das hat mit dem Linux Speichermanagement zu tun.
Der Kernel holt sich relativ viel Speicher und hat den unter seiner fuchtel, primär für eigene Dienste, kann die aber sehr schnell an Applikationen frei geben, wenn sie Speicher anfordern. Daher 48+1,5 = 51GB verfügbar.
https://linuxblog.io/free-vs-available-memory-in-linux/

[Michael Schmitt]

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)

[OliverIO]

@Michael-Schmitt

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.

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