Node.js 24 ist jetzt offiziell empfohlen!

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

[crunchip]

@Thomas-Braun für unraid/docker läuft das allerdings nicht so, da gibt es keinen swap, letztendlich muss ich dann in Kauf nehmen, das mein System nun 2GB mehr RAM benötigt. Zum Glück auf 64Gb aufgerüstet als die Preise noch human waren

[Thomas Braun]

@crunchip sagte:

für unraid/docker läuft das allerdings nicht so

Möglich. Aber da kenn ich mich wegen 'Docker'-Allergie auch nicht weiter aus.

[Thomas Braun]

@crunchip sagte:

Ich würde das anders sehen:

das mein System nun 2GB mehr RAM benötigt...

...aber dafür auch die Vorteile, die nodejs@24 mitbringt verwenden kann.

[Michael Schmitt]

Wenn ich das mit meinen Englischkentnissen richtig verstehe geht es doch hier genau um mein Problem und das dort auch noch keine Lösung gefunden wurde.

https://github.com/nodejs/node/issues/63863

https://github.com/nodejs/node/issues/61967#issuecomment-3983391832

[Thomas Braun]

@Michael-Schmitt

(V8 has since enabled that accounting by default, not yet in any Node release)

In V8 ist es wohl schon drin, das ist aber noch nicht in ein neues nodejs-Release geflossen.
Wie immer gilt: Keep updating.

[OliverIO]

@crunchip

Der swap wird vom os des Host System verwaltet.
Docker kapselt zwar die Prozesse, aber alle Prozesse müssen wegen Speicher den Host fragen. Der Host lagert dann nach gewissen Regeln aus. Egal ob der Prozess auf dem Host oder in einem Container läuft.

[crunchip]

@OliverIO Unraid hat nativ aber kein swap, wollte ich oben damit sagen. Man kann sich allerdings das zram plugin installieren