JavaScript heap out of memory beheben: Node.js Speicherlimit

Was bedeutet der Fehler JavaScript heap out of memory und was tun Sie zuerst?

JavaScript heap out of memory ist ein fataler Node.js Fehler. Er bedeutet, dass die V8 Engine ihren Heap gefüllt hat und der Garbage Collector nicht genug Platz freigeben konnte. Sie heben zuerst das Speicherlimit vorübergehend an und suchen dann die Aufgabe, die den Speicher wirklich verbraucht.

Bleiben Sie ruhig. In den meisten Fällen kommen Sie mit einer einzigen Zeile erst einmal am Absturz vorbei. Allerdings liegt die dauerhafte Lösung woanders. Wir beginnen mit den schnellen Schritten und kommen dann zu den Ursachen.

1. Notieren Sie, welcher Befehl den Fehler auslöst (ein Build, ein Server oder ein Skript).
2. Heben Sie das Limit für einen Lauf an: node --max-old-space-size=4096 app.js (der Wert ist nur ein Beispiel).
3. Starten Sie denselben Befehl erneut und prüfen Sie, ob der Fehler verschwindet.
4. Kommt der Fehler später zurück, vermuten Sie ein Speicherleck oder zu große Daten.
5. Folgen Sie der Diagnosereihenfolge in diesem Beitrag und setzen Sie eine dauerhafte Lösung um.

Diese Reihenfolge ist das, was wir in der Praxis sehen. Deshalb gehen wir von der wahrscheinlichsten zur unwahrscheinlichsten Ursache.

Warum meldet Node.js diesen Fehler überhaupt?

Node.js führt JavaScript mit der V8 Engine aus. V8 legt Objekte in einem Speicherbereich ab, den man Heap nennt. Dieser Bereich hat eine Obergrenze, und die Grenze kann niedriger sein als der gesamte Arbeitsspeicher Ihres Rechners.

Ist der Heap voll, versucht V8 zunächst eine Garbage Collection. Das heißt, es räumt Objekte auf, die niemand mehr nutzt. Gibt die Aufräumaktion zu wenig Platz frei, bricht der Prozess ab, und Sie sehen eine Meldung wie diese: FATAL ERROR: ... JavaScript heap out of memory.

Kurz gesagt, der Fehler bedeutet nicht immer, dass dem Rechner der Speicher ausgeht. Oft stoßen Sie nur an das V8 Limit. Dieser Unterschied ist wichtig, denn ein höheres Limit hilft zwar, beseitigt aber die Ursache nicht.

Der genaue Wortlaut kann je nach Node.js Version leicht abweichen. Sehen Sie also einen etwas anderen Text, dann behandeln Sie ihn als ähnliche Warnung und folgen demselben Diagnoseweg.

Wie setzen Sie die schnelle Lösung mit der Option max old space size um?

Die Option legt fest, wie viel Heap V8 für langlebige Objekte nutzen darf. Die Node.js Dokumentation gibt den Wert in MiB an. Sie schreiben die Option beim Start vor den Namen des Skripts.

node --max-old-space-size=4096 build.js

Der Wert 4096 ist nur ein Beispiel. Die richtige Zahl hängt vom Arbeitsspeicher Ihres Rechners und von den Aufgaben ab, die gleichzeitig laufen. Zum Beispiel lässt ein Wert von 4096 auf einem Rechner mit 8 GB Speicher noch Platz für das Betriebssystem und andere Prozesse.

Nach dem Setzen der Option passiert eines von zwei Dingen. Im ersten Fall läuft die Aufgabe durch, und das alte Limit war vermutlich nur zu knapp. Im zweiten Fall kommt der Fehler später, und das deutet meist auf ein Leck oder unkontrolliertes Wachstum hin.

Heben Sie das Limit also einmal an und beobachten Sie das Ergebnis. Erhöhen Sie es nicht blind immer weiter. Sonst verdecken Sie das eigentliche Problem monatelang.

Wie setzen Sie das Speicherlimit mit NODE_OPTIONS?

Manchmal können Sie den Befehl selbst nicht ändern, zum Beispiel in einem Paketskript oder einem CI Schritt. Dann nutzen Sie die Umgebungsvariable NODE_OPTIONS. Sie trägt erlaubte Optionen von außen in den Node.js Prozess.

export NODE_OPTIONS="--max-old-space-size=4096"
npm run build

Laut Node.js Dokumentation haben Optionen auf der Kommandozeile Vorrang vor Optionen aus NODE_OPTIONS. Setzen Sie dieselbe Option also zweimal mit verschiedenen Werten, gewinnt die Kommandozeile. Dieses Detail erklärt viele Meldungen nach dem Muster "die Einstellung wirkt nicht".

Prüfen Sie außerdem, ob die Variable den fehlerhaften Prozess wirklich erreicht. Ein Build Werkzeug startet vielleicht Kindprozesse, und die Option erreicht sie auf anderem Weg. Suchen Sie die Einstellung daher im fehlschlagenden Prozess, nicht nur dort, wo Sie sie eingetragen haben.

Für den dauerhaften Einsatz tragen Sie die Einstellung ins Projektskript oder in die Deployment Konfiguration ein. Dann arbeitet das ganze Team mit demselben Limit.

Wie wählen Sie ein Limit, ohne den Systemspeicher zu überschreiten?

Beginnen Sie mit dem echten Arbeitsspeicher des Rechners. Setzen Sie das Limit über den physischen Speicher, lagert das Betriebssystem auf die Festplatte aus. Die Anwendung wird langsam, und das System kann den Prozess sogar gewaltsam beenden.

Ein sicherer Weg sieht so aus. Denken Sie an die anderen Aufgaben auf dem Rechner, lassen Sie ihnen einen Anteil und geben Sie einen Teil des Rests an Node.js. Zudem ist der V8 Heap nur ein Teil des gesamten Speichers eines Prozesses. Puffer und native Erweiterungen verbrauchen Speicher außerhalb des Heaps.

Wir nennen keine feste Zahl, denn der richtige Wert hängt von der Last ab. Stattdessen empfehlen wir diese Reihenfolge:

• Starten Sie die fehlerhafte Aufgabe dort, wo Sie den Speicherverbrauch beobachten können.
• Heben Sie das Limit schrittweise an und notieren Sie jedes Ergebnis.
• Läuft die Aufgabe durch, addieren Sie zum Spitzenverbrauch einen kleinen Puffer.
• Halten Sie das Limit unter dem Speicher des Rechners.

Das Standardlimit kann sich zwischen Versionen ändern. Prüfen Sie den aktuellen Wert daher in der Node.js Dokumentation.

Warum ist die Option nur ein Pflaster und keine dauerhafte Lösung?

Ein höheres Limit ist wie ein größerer Eimer. Läuft der Wasserhahn weiter, füllt sich auch der große Eimer. In einer Anwendung mit Speicherleck verschiebt ein höheres Limit den Absturz nur nach hinten.

Andererseits kann ein höheres Limit eine vernünftige Brücke sein, wenn das Problem tatsächlich von einer großen Datenverarbeitung kommt. Auch dann bleiben zwei Risiken. Erstens durchsucht der Garbage Collector einen größeren Heap, sodass Pausen länger werden können. Zweitens wächst das echte Problem unbemerkt, weil der Absturz nicht mehr warnt.

Beispielszenario: Ein Team behebt einen Build Fehler mit einem höheren Limit. Monate später wächst das Projekt, und der Fehler kehrt zurück. Das Team erhöht das Limit erneut. Irgendwann reicht der CI Rechner nicht mehr, weil nie jemand die Ursache untersucht hat.

Betrachten Sie die Option deshalb als Werkzeug, das Zeit verschafft. Gehen Sie danach zur Diagnosereihenfolge weiter und setzen Sie eine dauerhafte Lösung um.

Was sind die häufigsten Ursachen für JavaScript heap out of memory?

Wir nennen die Ursachen in der Reihenfolge, in der wir sie in der Praxis sehen, beginnend mit der wahrscheinlichsten. Prüfen Sie zuerst die häufigste Ursache, denn das spart Zeit.

1. Ein großer Build: Viele Module, Source Maps und Plugins verbrauchen Speicher im selben Prozess.
2. Große Daten auf einmal laden: Eine ganze Datei lesen oder eine riesige Antwort in einem Stück auswerten.
3. Ein Speicherleck: Speicher, der in einem lange laufenden Server langsam wächst.
4. Unbegrenzte Caches oder Warteschlangen: Eine Liste oder ein Objekt, das nie geleert wird.
5. Ein Container oder CI Limit: Eine Umgebung mit weniger Speicher, als die App braucht.

Jede Ursache zeigt eigene Symptome. Ein Build Fehler wiederholt sich meist im selben Schritt. Ein Leck sieht anders aus, denn der Server läuft stunden oder tagelang gesund und stürzt dann ab. Dieser Unterschied beschleunigt die Diagnose.

Die nächsten Abschnitte behandeln jede Ursache einzeln. Außerdem verbindet die Vergleichstabelle weiter unten jedes Symptom mit der passenden Ursache.

Warum geht bei einem großen Build der Speicher aus?

In modernen Frontend Projekten lädt das Build Werkzeug den gesamten Abhängigkeitsbaum in den Speicher. Danach wandelt es den Code um, bündelt ihn und verkleinert ihn. Wächst das Projekt, wächst auch der Spitzenbedarf an Speicher.

Den Fehler sehen Sie meist bei npm run build. Zum Beispiel läuft ein Build auf Ihrem Laptop problemlos und stürzt auf einem CI Rechner mit weniger Speicher ab. Der Code hat sich nicht geändert, nur die Umgebung.

Stellen Sie bei Build Fehlern diese Fragen in dieser Reihenfolge:

• Tritt der Fehler immer im selben Schritt auf, etwa beim Verkleinern?
• Ist die Erzeugung von Source Maps eingeschaltet?
• Wie viele Dateien werden parallel verarbeitet?
• Hat sich kürzlich eine große Abhängigkeit geändert?

Bekamen Sie nach dem Hinzufügen einer Abhängigkeit einen Installationsfehler, hilft Ihnen vielleicht unsere Anleitung zum npm ERESOLVE Fehler. Denn wer einen Abhängigkeitskonflikt erzwingt, holt sich manchmal Pakete ins Projekt, die den Build aufblähen.

Warum löst das Laden großer Daten in den Speicher diesen Fehler aus?

Wenn Sie eine Datei oder ein Datenbankergebnis in einem Aufruf lesen, landet der gesamte Inhalt im Heap. Wandeln Sie zum Beispiel eine CSV Datei mit mehreren hundert Megabyte in einen einzigen Text um, liegen sowohl der Rohtext als auch die ausgewerteten Objekte im Speicher. Somit braucht der Prozess ein Vielfaches der Dateigröße.

Ebenso verlangt das Auswerten einer großen JSON Antwort in einem Stück mehr Speicher als die Antwort selbst. Denn beim Auswerten entstehen Zwischenobjekte. Deshalb kann Code, der gestern lief, bei wachsenden Daten plötzlich scheitern.

Das typische Symptom lautet: Mit kleinen Testdateien läuft alles, mit echten Daten stürzt es ab. Anders gesagt, der Code ist nicht falsch, er skaliert nur nicht.

Die Richtung der Lösung ist klar. Verarbeiten Sie die Daten in Stücken statt als Ganzes. Der nächste Abschnitt zeigt, wie das geht.

Wie schützt die Verarbeitung mit Streams den Speicher?

Ein Stream liest und verarbeitet Daten in kleinen Teilen. Denken Sie an Wasser in einem Rohr statt Wasser in einem Eimer. Nur eine kleine Menge liegt jeweils im Speicher. Die Node.js Dokumentation stellt dieses Modell als Stream API vor.

Konzeptionell gibt es drei Schritte. Zunächst öffnen Sie die Quelle als Stream. Dann verarbeiten Sie jedes Teil. Schließlich schreiben Sie das Ergebnis ins Ziel. Weil die Teile einzeln durchlaufen, wächst der Speicherverbrauch nicht mit der Dateigröße.

const { pipeline } = require('node:stream/promises');
await pipeline(eingabe, umwandlung, ausgabe);

Zeilenbasierte Dateien folgen derselben Idee, denn Sie behandeln jede Zeile einzeln. Bei Datenbankabfragen ist es viel sicherer, Ergebnisse seitenweise zu holen, als die ganze Tabelle zu laden.

Achten Sie bei Streams auf einen Punkt: ein langsames Ziel. Kommt das Ziel nicht hinterher, können sich Daten im Speicher stauen. Bauen Sie die Kette daher mit Pipeline Helfern statt mit rohen Ereignis Listenern. Details finden Sie in der Node.js Dokumentation zu Streams.

Woran erkennen Sie ein Speicherleck?

Ein Speicherleck entsteht, wenn Objekte, die Sie nicht mehr brauchen, von irgendwoher weiter referenziert werden. Der Garbage Collector entfernt nur Objekte, die nicht mehr erreichbar sind. Ein in einer Liste vergessenes Objekt bleibt also für immer.

Das Symptom sieht meist so aus. Die App startet, der Speicher steigt langsam und sinkt nie. Selbst wenn der Verkehr nachlässt, bleibt der Speicher gleich. Irgendwann stürzt der Prozess ab, startet neu, und der Kreislauf beginnt von vorn.

Häufige Leck Muster sind diese:

• Globale Caches und Objektlisten, die nie bereinigt werden.
• Ereignis Listener, die nie entfernt werden.
• Timer und Verbindungen, die nie geschlossen werden.
• Arrays, die mit jeder Anfrage wachsen und nie geleert werden.

Um ein Leck zu belegen, verfolgen Sie den Speicherverbrauch über die Zeit. Sehen Sie statt einer flachen Linie eine stetig steigende Treppe, wird der Verdacht stärker. Auch Serverprotokolle helfen, und dafür können Sie unser kostenloses Tool zur Logfile Analyse nutzen.

Wie erstellen und lesen Sie einen Heap Snapshot?

Ein Heap Snapshot ist ein Foto des Heaps zu einem bestimmten Zeitpunkt. Er zeigt, welche Objekttypen wie viel Platz belegen und wer sie festhält. Bei der Suche nach einem Leck ist er das stärkste Werkzeug.

Laut Node.js Dokumentation sorgt die Option --heapsnapshot-signal dafür, dass der Prozess einen Heap Dump schreibt, wenn das gewählte Signal eintrifft. Die Option --heapsnapshot-near-heap-limit schreibt einen Dump, wenn der Heap sich seinem Limit nähert. Allerdings weist die Dokumentation darauf hin, dass ein Snapshot Zeit und Speicher kostet.

node --heapsnapshot-signal=SIGUSR2 server.js
kill -USR2 PROZESS_ID

Am besten erstellen Sie zwei Snapshots: einen kurz nach dem Start und einen, nachdem der Speicher gewachsen ist. Dann vergleichen Sie beide. Ein Objekttyp, der im zweiten Snapshot deutlich zunimmt, zeigt auf das Leck.

Seien Sie in der Produktion vorsichtig. Eine Snapshot Datei kann sensible Daten enthalten, und der Prozess wird beim Schreiben langsamer. Bewahren Sie die Datei deshalb sicher auf und löschen Sie sie danach.

Wie untersuchen Sie den Speicher mit Inspect und Chrome DevTools?

Node.js öffnet mit der Option --inspect einen Debugging Port. Chrome DevTools verbindet sich damit. Im Speicher Bereich können Sie Heap Snapshots erstellen, Objekttypen sortieren und Referenzketten verfolgen.

node --inspect server.js

Nach der Verbindung erstellen Sie Snapshots im Bereich Memory. Die Vergleichsansicht listet den Unterschied zwischen zwei Snapshots auf. Somit sehen Sie schnell, welche Objekte sich ansammeln. Details finden Sie in der Chrome DevTools Dokumentation zu Speicherproblemen.

Sicherheitshinweis: Die Node.js Dokumentation warnt, dass es unsicher ist, den Inspector an eine öffentliche IP und einen öffentlichen Port zu binden. Nutzen Sie den Debugging Port daher nur auf Ihrem lokalen Rechner oder über einen sicheren Tunnel.

Schlägt die Verbindung fehl, liegt die Ursache oft am Port. Dann führt Sie unsere Anleitung zu localhost Verbindung abgelehnt durch die Prüfschritte.

Wie stellen Sie Parallelität und Source Maps in Build Werkzeugen ein?

Bei Speicherproblemen im Build machen zwei Einstellungen oft den Unterschied. Das sind die Zahl der parallelen Aufgaben und die Erzeugung von Source Maps. Die Namen der Optionen unterscheiden sich je nach Werkzeug, prüfen Sie den genauen Namen daher in der Dokumentation Ihres Werkzeugs.

Die Logik der Parallelität ist einfach. Jede parallele Aufgabe verlangt ihren eigenen Anteil am Speicher. Reduzieren Sie also die Zahl gleichzeitiger Aufgaben, sinkt der Spitzenverbrauch, aber der Build dauert länger. Auf einem CI Rechner mit knappem Speicher lohnt sich dieser Tausch oft.

Source Maps erleichtern das Debugging, kosten bei der Erzeugung aber Speicher. In Produktions Builds kann ein leichterer Map Typ oder das Abschalten der Maps den Verbrauch deutlich senken. Die Entscheidung hängt dennoch davon ab, wie Sie Fehler verfolgen.

Bedenken Sie außerdem diese Schritte:

• Entfernen Sie ungenutzte Abhängigkeiten.
• Importieren Sie von großen Bibliotheken nur den Teil, den Sie brauchen.
• Aktivieren Sie den Build Cache und halten Sie ihn sauber.

Auch die Ladezeit Ihrer Seite hängt damit zusammen. Mehr dazu lesen Sie in unserem Beitrag zur JavaScript Ladezeit.

Warum ist das Speicherlimit in CI und Containern ein eigenes Problem?

Ein Prozess im Container sieht nicht unbedingt den gesamten Speicher des Hosts. Hat der Container ein Speicherlimit, beendet das Betriebssystem jeden Prozess, der es überschreitet. In diesem Fall kann der Prozess ganz ohne V8 Fehlermeldung verschwinden.

Sie müssen zwei Limits trennen. Das erste ist das V8 Heap Limit, das Sie mit --max-old-space-size setzen. Das zweite ist das Speicherlimit des Containers oder CI Runners. Liegt das V8 Limit über dem Container Limit, beendet der Container den Prozess, bevor V8 etwas melden kann.

Halten Sie das V8 Limit daher unter dem Container Limit. Dann kommt der Fehler als lesbare Meldung statt als stiller Abbruch. Wie Ressourcenlimits für Container definiert werden, lesen Sie in der Docker Dokumentation zu Ressourcenbeschränkungen.

Möchten Sie bei den Grundlagen anfangen, ist unser Leitfaden zu Docker ein guter Einstieg. Denken Sie daran, dass derselbe Code lokal läuft und in CI abstürzen kann, weil die Umgebungen nicht gleich viel Speicher bieten.

Sollten Sie einen Neustart bei Speicherschwelle mit PM2 nutzen?

PM2 ist ein Prozessmanager für Node.js Anwendungen. Er hat eine Option, die einen Prozess automatisch neu startet, wenn der Speicher eine Schwelle überschreitet. Sie legen die Schwelle in Ihrer Konfigurationsdatei fest und prüfen den genauen Namen der Option in der PM2 Dokumentation.

Diese Funktion verringert Abstürze, die Nutzer spüren, bis Sie das Leck gefunden haben. Das heißt, der Server wird kontrolliert erneuert, statt nachts abzustürzen und bis zum Morgen auszufallen. In der Produktion dient sie als vorübergehender Sicherheitsgurt.

Andererseits löst sie das Problem nicht. Ein Neustart beseitigt das Leck nicht, er mildert nur das Ergebnis. Außerdem können offene Verbindungen beim Neustart abbrechen. Sehen Sie die Schwelle daher als Brücke, nicht als Heilung.

Unser Rat lautet: Aktivieren Sie die PM2 Schwelle, suchen Sie das Leck parallel mit Heap Snapshots und lassen Sie die Schwelle danach als Sicherheitsnetz bestehen. PM2 von Grund auf lernen Sie in unserem Beitrag Was ist PM2.

Tritt JavaScript heap out of memory nur auf Servern auf?

Nein. Der Fehler kann überall auftreten, wo Node.js läuft. Paketinstallationen, Test Runner, Typprüfer, Build Werkzeuge und einmalige Datenskripte sind die üblichen Orte. Das Problem hängt also am Speicherverhalten des Node.js Prozesses, nicht am Wort Server.

Zum Beispiel kann ein Entwickler denselben Fehler auf dem Laptop beim Testbefehl sehen. Dann läuft kein Server, aber eine große Testsuite frisst den Speicher. Daher lautet die Diagnosefrage immer gleich: Welcher Befehl, in welcher Phase, mit wie vielen Daten?

Diese Unterscheidung ist wichtig, weil die Lösungen verschieden sind. In einem einmaligen Skript kann ein höheres Limit vernünftig sein. In einem dauerhaft laufenden Server verdeckt derselbe Schritt ein Leck. Notieren Sie deshalb zuerst, welche Art von Prozess scheitert, und gehen Sie dann zum passenden Abschnitt.

Welche Diagnosereihenfolge sollten Sie bei diesem Fehler einhalten?

Unsere Reihenfolge geht von der billigsten zur teuersten Prüfung. So verlieren Sie keine Stunden. Ändern Sie immer nur eine Sache auf einmal, denn bei drei gleichzeitigen Änderungen wissen Sie nicht, welche geholfen hat.

1. Halten Sie fest, welcher Befehl und welche Phase den Fehler auslösen.
2. Vergleichen Sie die Umgebungen: Unterscheidet sich der Speicher auf Ihrem Rechner, in CI und im Container?
3. Heben Sie das Limit einmal an und prüfen Sie, ob sich der Fehler verzögert.
4. Verzögert er sich, messen Sie das Speicherwachstum über die Zeit.
5. Wächst der Speicher stetig, erstellen Sie zwei Heap Snapshots und vergleichen Sie sie.
6. Folgt das Wachstum der Datenmenge, wechseln Sie zu Streams oder Seitenabruf.
7. Setzen Sie die dauerhafte Lösung um und richten Sie einen Speicheralarm ein.

Die Logik ist einfach. Der Umgebungsvergleich ist die billigste Prüfung und oft die häufigste Ursache. Ein Snapshot ist der teuerste Schritt und steht daher fast am Ende.

Speichern Sie außerdem nach jedem Versuch eine kurze Notiz. Wenn Sie festhalten, wie stark sich der Fehler bei jedem Limit verzögerte, sehen Sie, ob das Problem mit den Daten oder mit der Zeit wächst.

Wie wirken sich Garbage Collection und Heap Größe auf die Geschwindigkeit aus?

Während der Garbage Collector läuft, kann die Anwendung kurz pausieren. Wächst der Heap, müssen mehr Objekte durchsucht werden, und die Pausen können länger werden. Ein sehr hohes Limit kann daher die Antwortzeiten verschlechtern, selbst wenn Sie den Fehler nie sehen.

Das Symptom erkennen Sie so. Die App stürzt nicht ab, friert aber ab und zu für einige Sekunden ein. In der Speichergrafik sehen Sie ein Sägezahnmuster. Anders gesagt, der Collector läuft oft und lange.

Ein größerer Heap hilft dann selten. Stattdessen müssen Sie weniger Objekte erzeugen. Verwenden Sie zum Beispiel große Objekte wieder, die Sie bei jeder Anfrage neu aufbauen, und halten Sie temporäre Arrays klein.

Kurz gesagt, Speicher ist nicht nur ein Absturzproblem, sondern auch ein Leistungsproblem. Die dauerhafte Lösung ist ein Design, das weniger Speicher braucht.

Beispielszenario: Wie beheben Sie den Fehler in einem Berichtsskript?

Stellen Sie sich ein Skript vor, das jede Nacht alle Bestelldatensätze liest und eine Berichtsdatei schreibt. In den ersten Monaten läuft es problemlos. Wächst die Zahl der Datensätze, stürzt es eines Nachts mit einem JavaScript heap out of memory Fehler ab.

Das Team hebt zuerst das Limit an, und das Skript läuft wieder. Einige Monate später kehrt der Fehler zurück. Diesmal diagnostiziert das Team und sieht, dass das Skript alle Datensätze in einem Array sammelt. Konkret wächst der Speicherbedarf direkt mit der Zahl der Datensätze.

Die dauerhafte Lösung besteht aus diesen Schritten:

• Datensätze seitenweise abrufen.
• Jede Seite verarbeiten und sofort in die Ausgabe schreiben.
• Die verarbeitete Seite aus dem Speicher freigeben.
• Den Spitzenverbrauch des Skripts einmal messen und notieren.

Somit hängt der Speicherverbrauch nicht mehr von der Zahl der Datensätze ab. Dieses Szenario ist erfunden, spiegelt aber ein Muster, das wir oft sehen.

Wann sollten Sie die Architektur ändern statt die Option?

Manche Aufgaben gehören nicht in den Speicher. Das Umwandeln sehr großer Dateien, das Zusammenführen riesiger Datenmengen und aufwendige Bildverarbeitung sind Beispiele. Führen Sie sie im Hauptprozess Ihrer Anwendung aus, gefährden Sie alle Nutzer.

Verlagern Sie schwere Aufgaben daher in einen eigenen Prozess oder in einen Worker mit Warteschlange. Dann trifft ein Speicherproblem nur diesen Worker, und die Hauptanwendung läuft weiter. Zudem können Sie dem Worker ein eigenes Speicherlimit geben.

Andererseits braucht nicht jedes Problem eine Architekturänderung. Ist die Aufgabe klein und einmalig, genügt ein höheres Limit. Fragen Sie zur Entscheidung: Wächst die Aufgabe weiter? Lautet die Antwort ja, ist es günstiger, das Design jetzt zu korrigieren als später.

Welche Methode wählen Sie wann?

Die folgende Tabelle vergleicht die Methoden nach Einsatzzeitpunkt und Risiko. Sie fasst die Diagnosereihenfolge dieses Beitrags zusammen.

Merken Sie sich beim Lesen der Tabelle: Keine Methode reicht allein. In den meisten echten Fällen heben Sie zuerst das Limit an, suchen dann die Ursache und setzen am Ende die dauerhafte Methode um.

Welche Checkliste sichert die dauerhafte Vorbeugung?

Nach der Lösung des Problems hilft Ihnen diese Liste, es nicht wieder zu erleben. Sie dient Softwareteams als kurze Wartungsroutine.

• Überwachen Sie den Speicherverbrauch regelmäßig und legen Sie eine Alarmschwelle fest.
• Verarbeiten Sie große Daten immer mit Streams oder seitenweise.
• Geben Sie jedem Cache ein Größenlimit und ein Ablaufdatum.
• Entfernen Sie Ereignis Listener und Timer, wenn die Arbeit endet.
• Dokumentieren Sie die Speicherlimits von CI und Containern.
• Aktualisieren Sie Abhängigkeiten regelmäßig und löschen Sie ungenutzte.
• Nutzen Sie in der Produktion einen Manager wie PM2 mit Sicherheitsschwelle.
• Führen Sie vor jedem größeren Release einmal einen Speichertest aus.

Kurz gesagt, das Ziel ist, den Speicher sichtbar zu machen, statt auf den Fehler zu warten. So fangen Sie das Problem ab, bevor es die Nutzer erreicht.

Es hilft auch, die Liste an einen Wartungskalender zu knüpfen. Machen Sie die Speicherprüfung zum Beispiel zu einem gemeinsamen Schritt vor jedem Release. Dann übernehmen neue Entwickler dieselbe Gewohnheit. Betreiben Sie eine Node.js Anwendung auf einem Server, behandelt unsere Anleitung zum Node.js Deployment die Einrichtung.

Wie erhalten Sie bei diesem Problem Unterstützung von unserem Team?

Speicherprobleme lassen sich manchmal nicht mit einer einzelnen Einstellung lösen. Die Suche nach Lecks, die Optimierung der Build Pipeline und der Neuentwurf eines großen Datenflusses brauchen Zeit und Erfahrung. An diesem Punkt unterstützen Sie Talha Aslan und unser Team mit unserer individuellen Softwareentwicklung.

Beschreiben Sie Ihren Bedarf kurz, dann klären wir den Umfang gemeinsam. Details finden Sie auf unserer Seite zur individuellen Softwareentwicklung, wo Sie auch ein Angebot anfordern können.

Die Schritte in diesem Beitrag reichen in den meisten Fällen, um selbst voranzukommen. Außerdem decken die npm und localhost Anleitungen aus derselben Reihe andere häufige Probleme in derselben Entwicklungsumgebung ab.

Hinweis: Dieser Inhalt ist allgemeine Information. Prüfen Sie Befehle und Optionsnamen in der offiziellen Dokumentation Ihrer Node.js Version, denn Optionen können sich im Lauf der Zeit ändern. Nutzen Sie zudem die Node.js Dokumentation zur Kommandozeile als Hauptquelle.