Node.js 24 ist jetzt offiziell empfohlen!

[fritzke316]

Ich habe das selbe bemerkt seit dem Update auf Admin 8 und nodejs 24 braucht mein Pi4 8GB viel mehr RAM vorher ca. 50% nun nach etwas Laufzeit 80% und mehr.
Nach einem Neustart sind es 54%

[Thomas Braun]

nodejs 24 verwendet vorhandene Speicher jetzt einfach effizienter und ist dadurch schneller.
Eine Auslastung von 80% ist auch erstmal per se nicht kritisch.
Dazu stellt man auch am besten eine ausreichend großes SWAP zur Verfügung. Neue Grundinstallationen von z. B. RaspberryOS tun das seit einiger Zeit von Haus aus. Auf meinem 8GB Pi4 wurden unlängst direkt 2GB als SWAP eingerichtet.

Auf weitere unnötige Speicherfresser wie einen Desktop verzichtet man ja ohnehin (aus diversen Gründen).
So lange der ioBroker nicht vom OutOfMemory-Daemon gekillt wird sehe ich da keinen Grund für Sorgen.

[fritzke316]

Ich war jetzt nicht direkt in Sorge, wollte nur darauf hinweisen.
Mein System läuft soweit gut und solange der Speicher reicht ist alles gut :)

[Michael Schmitt]

@Thomas-Braun sagte:

nodejs 24 verwendet vorhandene Speicher jetzt einfach effizienter und ist dadurch schneller.
Eine Auslastung von 80% ist auch erstmal per se nicht kritisch.
Dazu stellt man auch am besten eine ausreichend großes SWAP zur Verfügung. Neue Grundinstallationen von z. B. RaspberryOS tun das seit einiger Zeit von Haus aus. Auf meinem 8GB Pi4 wurden unlängst direkt 2GB als SWAP eingerichtet.

Auf weitere unnötige Speicherfresser wie einen Desktop verzichtet man ja ohnehin (aus diversen Gründen).
So lange der ioBroker nicht vom OutOfMemory-Daemon gekillt wird sehe ich da keinen Grund für Sorgen.

und mein Raspi4 4gb der muß dann weg ? Ich hatte noch 200mb free Ram und 500mb available

[Thomas Braun]

@Michael-Schmitt sagte:

und mein Raspi4 4gb der muß dann weg ?

Das hängt sehr von deiner individuellen Situation ab. Grundsätzlich ist das ja kein Problem, sind ja noch 500MB verfügbar. Die Angabe von 'free' ist ja auch eher uninteressant. Du fährst dein Auto ja auch nicht halb in die Garage, damit dann zwischen Wand und Stoßstange was 'free' bleibt.

[Michael Schmitt]

von 24 wieder auf 22 und das ist der Unterschied

2.10.2026 15:40:00;Node=24.21.0;RSS=1023.64MB;HeapUsed=144.23MB;HeapTotal=152.14MB;MemAvail=512MB;Mem%=87
2.10.2026 15:50:00;Node=24.21.0;RSS=1157.29MB;HeapUsed=145.58MB;HeapTotal=154.64MB;MemAvail=354MB;Mem%=91
2.10.2026 15:52:50;Node=22.23.3;RSS=483.38MB;HeapUsed=216.9MB;HeapTotal=243.74MB;MemAvail=1849MB;Mem%=54
2.10.2026 15:58:57;Node=22.23.3;RSS=560.63MB;HeapUsed=260.97MB;HeapTotal=304.48MB;MemAvail=1826MB;Mem%=54
2.10.2026 16:00:00;Node=22.23.3;RSS=549.11MB;HeapUsed=187.82MB;HeapTotal=218.71MB;MemAvail=892MB;Mem%=78
2.10.2026 16:10:00;Node=22.23.3;RSS=401.5MB;HeapUsed=145.98MB;HeapTotal=186.21MB;MemAvail=1288MB;Mem%=68
2.10.2026 16:20:00;Node=22.23.3;RSS=406.07MB;HeapUsed=139.66MB;HeapTotal=161.64MB;MemAvail=1259MB;Mem%=68
2.10.2026 16:30:00;Node=22.23.3;RSS=398.19MB;HeapUsed=143.67MB;HeapTotal=150.38MB;MemAvail=1200MB;Mem%=70

[Thomas Braun]

@Michael-Schmitt sagte:

von 24 wieder auf 22 und das ist der Unterschied

Was ist denn KONKRET dein Problem? Werden Prozesse gekillt? Funktioniert dein automatisches Backup nachts nicht mehr?

[crunchip]

@Thomas-Braun naja, aber was ist dann effizient?
Das Auto steht zur Hälfte im Regen, weil ja vorn "free", dafür bau ich mir vor die Garage noch ne Überdachung, damit`s Auto nicht nass wird.

[Michael Schmitt]

Deswegen hab ich ne Garage wo zwei Autos hintereinander rein gehen und noch Fahrräder davor So Bespiele liebe ich.

Mein Problem ist das mein kleines System ohne mein zutun immer weiter aufgeblasen wird und ich über kurz oder lang Geld ausgeben muß um das am laufen zu halten.

[Thomas Braun]

@crunchip sagte:

naja, aber was ist dann effizient?

Effizient wäre es, den vorhandenen RA(u)M zu verwenden und nicht brach liegen zu lassen.

[crunchip]

@Thomas-Braun der vorhandene sind ja die 4GB echten , sobald kontinuierlich Swap in Anspruch genommen wird, sehe ich das nicht als effizient an

[Thomas Braun]

@crunchip

Das überlasse ich dem Memory-Management des Kernels. Der weiß i. d. R. wo gewisse Daten momentan am besten aufgehoben sind.

[crunchip]

@Thomas-Braun was man im Bedarfsfall aber auch optimieren könnte

[OliverIO]

@Michael-Schmitt

das ist leider der lauf der Aktualität.
du kannst ja mal probieren windows 11 auf einen rechner zu installieren wo win95 lief.
ob diese entwicklung gut ist? die einen sprechen von geplanter obsolezenz, die anderen von Sicherheit und mehr Anforderungen.

[rscsb]

@crunchip sagte:

der vorhandene sind ja die 4GB echten , sobald kontinuierlich Swap in Anspruch genommen wird, sehe ich das nicht als effizient an

Das sollte man nicht so getrennt sehen. Sogar bei Systemen die mehrere zehn- oder hunderttausend Euro kosten wird das bei der Konfiguration als "Arbeitsspeicher" geplant. Der besteht dann aus schnellem Speicher (RAM) und langsamerem (SWAP).

Aber ja, man kann sich damit auch Nachteile erschaffen. Mehr Datenverkehr auf dem Bus - mehr Zugriffe auf Platte oder SSD. SD-Karte ist natürlich dann fast ein no-go.
Aber verteufeln sollte man diese "Technik" nicht.

[Thomas Braun]

Mein Hauptsystem schaut momentan so aus:

echad@chet:~ $ free -h
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:      7,6Gi       6,2Gi       640Mi       238Mi       1,1Gi       1,4Gi
Swap:          2,0Gi       533Mi       1,5Gi
echad@chet:~ $

Und das macht mir gerade gar keine Kopfschmerzen. Gut, die Basis ist da mit 8GB auch erstmal für 'Stand heute' groß genug. Irgendwann wird da aber auch mal ein Hardware-Upgrade fällig werden. Aber das ist ja überall so. Eine ausreichende Ausstattung von vor einigen Jahren reicht heute auch nicht mehr aus. Wie viele eigentlich gut ausgestatte Computer sind z. B. nicht mehr mit Windows 11 kompatibel?

Edit: Die KI bekommt da auch keine Kopfschmerzen, zumal SWAP ja als ZRAM angelegt ist und daher das Speichermedium nicht physisch belastet:

Aktueller Zustand
• Arbeitsspeicher (RAM): Das System verfügt über 8 GB Gesamtspeicher (7,6 GiB netto). Davon sind aktuell rund 80 % ausgelastet (6,2 GiB benutzt). Es verbleibt eine absolut ausreichende Reserve von 1,4 GiB verfügbarem Speicher für Lastspitzen.
• Auslagerungsspeicher (Swap): Es sind 2,0 GiB Swap eingerichtet, wovon derzeit 533,8 MiB (ca. 25 %) aktiv genutzt werden.
Besonderheit & Hardware-Schonung
• Reines ZRAM-Setup: Die Überprüfung hat gezeigt, dass der Swap exklusiv als zram0 im Arbeitsspeicher läuft.
• Keine SSD-Belastung: Daten werden nicht physisch auf die verbaute Transcend-SSD geschrieben, sondern hochkomprimiert im RAM abgelegt. Dies verhindert jeglichen SSD-Verschleiß durch Auslagerungsprozesse.
• Optimale Performance: Durch die Auslagerung in den komprimierten RAM bleibt das System trotz der hohen RAM-Auslastung extrem schnell und effizient.
Gesamtfazit: Das System läuft unter spürbarer, aber völlig gesunder Last.

Es ist optimal konfiguriert, nutzt die Hardware perfekt aus und erfordert aktuell keinerlei administrativen Handlungsbedarf.

[Thomas Braun]

Ich hab gerade mal nach Benchmarks geschaut. Hier

https://medium.com/@quicksilversel/i-upgraded-from-node-20-to-24-and-cpu-usage-dropped-i-didnt-change-any-code-d9c2cadcda85

wird z. B. gesagt:

The Memory Number That Almost Worried Me

Here’s something I noticed mid-investigation that nearly sent me down a wrong path: heap_size_limit went up after the upgrade.

My first reaction was “uh oh.” Higher heap ceiling sounds like the app is reaching for more memory. Is something leaking?

No. It’s actually a good sign.

Newer V8 versions (around Node 22+) include heuristics that set the default New Space size dynamically based on available system memory, instead of using static defaults. V8 is now giving itself a larger ceiling to work with.

Here’s why that’s good:

A larger buffer for newly allocated objects gives the rapid Scavenge collector more time to identify and reclaim short-lived garbage before the allocation space fills up. That reduces premature promotion to Old Space. Which reduces the frequency of slow, disruptive Old Space (major) GC cycles.

In other words:

Higher heap_size_limit → fewer major GC cycles → less CPU usage and lower event loop delays.

The runtime is trading a little memory headroom for dramatically less GC pressure. In production, RAM is almost always more abundant than CPU cycles. It’s the right trade.

[FernetMenta]

@michael-schmitt magst du mal dein Javescript posten, das dir die Werte ausgibt? Vielleicht könnten das ja mal paar Leute hier auch laufen lassen. Dann kann man das vergleichen.

[Michael Schmitt]

@FernetMenta sagte:

@michael-schmitt magst du mal dein Javescript posten, das dir die Werte ausgibt? Vielleicht könnten das ja mal paar Leute hier auch laufen lassen. Dann kann man das vergleichen.

Klar,

es wird unter "0_userdata.0.monitoring.memoryLog" ein Datenpunkt automatsch angelegt und dort kann man sich das rauskopieren

In der Vorletzten Zeile im script kann man einstellen in welchen Zyklus die Werte aufgezeichnet werden sollen.
schedule('*/30 * * * *', logMemory); = alle 30min

const LOG_STATE = '0_userdata.0.monitoring.memoryLog';
const MAX_LINES = 500; // ca. 10 Tage bei 30-Min-Takt

// Host-ID zuverlässig über vorhandene memRss-States ermitteln
let HOST_ID = null;
const hostStates = $('system.host.*.memRss');
if (hostStates.length) {
    HOST_ID = hostStates[0].replace('.memRss', '');
    log('Verwende Host: ' + HOST_ID);
} else {
    log('Konnte Host-ID nicht ermitteln! Prüfe, ob system.host.*.memRss existiert.', 'error');
}

// Datenpunkt einmalig anlegen, falls nicht vorhanden
if (!existsState(LOG_STATE)) {
    createState(LOG_STATE, '', {
        name: 'RAM-Verlauf js-controller',
        type: 'string',
        role: 'text',
        read: true,
        write: false
    });
}

function logMemory() {
    if (!HOST_ID) {
        log('Logging übersprungen, HOST_ID nicht gesetzt.', 'warn');
        return;
    }

    const rss = getState(HOST_ID + '.memRss').val;
    const heapUsed = getState(HOST_ID + '.memHeapUsed').val;
    const heapTotal = getState(HOST_ID + '.memHeapTotal').val;
    const memAvail = getState(HOST_ID + '.memAvailable').val;
    const memPercent = getState(HOST_ID + '.mem').val;
    const nodeVer = getState(HOST_ID + '.nodeVersion').val;

    const now = new Date();
    const ts = now.toLocaleDateString('de-DE') + ' ' + now.toLocaleTimeString('de-DE');

    const line = `${ts};Node=${nodeVer};RSS=${rss}MB;HeapUsed=${heapUsed}MB;HeapTotal=${heapTotal}MB;MemAvail=${memAvail}MB;Mem%=${memPercent}`;

    let current = getState(LOG_STATE).val || '';
    let lines = current ? current.split('\n') : [];
    lines.push(line);

    if (lines.length > MAX_LINES) {
        lines = lines.slice(lines.length - MAX_LINES);
    }

    setState(LOG_STATE, lines.join('\n'), true);
    log('Memory-Log geschrieben: ' + line, 'debug');
}

schedule('*/30 * * * *', logMemory);
logMemory();

[FernetMenta]

Ok, das ist einfach das, was iob unter system hat. Mir ist auf meinem System PI 5 mit 8G nicht aufgefallen, dass Node 24 mehr Speicher benötigen würde. Zumindest nicht wenn auf die Zahlen schaut, was z.B. free ausgibt oder in iob bei RAM steht. Nur auf RSS schauen kann die Tatsachen verfälschen.

Ich betreibe auch noch einen iob slave auf einem PI3 mit 1G RAM. Da hätte ich sofort bemert, wenn Node 24 jetzt viel mehr Spreicher benötigen würde.