Der Build bricht mit „heap out of memory“ ab? Node hat ein festes Speicherlimit — man kann es anheben, sollte aber zuerst nach der Ursache suchen.
Aufwand:
ca. 25 Min.
Das Symptom
Ein Build, ein Test-Durchlauf oder ein Node-Skript läuft eine Weile und stürzt dann
ab mit FATAL ERROR: ... JavaScript heap out of memory. Oft passiert es bei
größeren Projekten, in der Continuous-Integration-Umgebung oder erst, seit das
Projekt gewachsen ist.
Die „Layer 8“-Wahrheit
Node.js gibt dem JavaScript-Speicher eine feste Obergrenze — historisch recht
knapp bemessen, weil JavaScript ursprünglich nicht für riesige Builds gedacht war.
Stößt ein Vorgang an diese Decke, beendet Node ihn kontrolliert, statt den ganzen
Rechner leerzusaugen. Der Fehler ist also eine Bremse, kein Defekt, und die
Verlockung ist groß, die Bremse einfach zu lösen und das Limit hochzuschrauben.
Das ist manchmal richtig — ein großer, moderner Build braucht real mehr als die
alte Voreinstellung. Genauso oft aber verdeckt ein höheres Limit nur das eigentliche
Problem: eine Schleife, die Objekte anhäuft, ein Vorgang, der eine riesige Datei
komplett in den Speicher lädt, ein Leck, das nach jeder Codeänderung wächst. Der
ehrliche Weg ist deshalb, erst zu fragen, warum so viel Speicher nötig ist — und
das Limit nur dann anzuheben, wenn der Bedarf wirklich gerechtfertigt ist.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Das feste Speicherlimit verstehen
Node begrenzt den Speicher (Heap) für JavaScript bewusst. Erreicht ein großer Build oder ein Prozess diese Grenze, bricht er mit „heap out of memory“ ab. Das ist kein Absturz, sondern ein Schutzlimit — die Frage ist, ob der Bedarf berechtigt ist oder ein Leck vorliegt.
2.
Das Limit testweise anheben
Für einen legitim großen Build lässt sich das Limit über eine Umgebungsvariable erhöhen — hier auf 4 GB. Danach den Befehl erneut ausführen:
export NODE_OPTIONS=--max-old-space-size=4096
3.
Prüfen, ob wirklich mehr Speicher nötig ist
Bevor man das Limit dauerhaft hochsetzt: Vielleicht lädt der Build unnötig viel auf einmal, oder eine Endlosschleife häuft Objekte an. Ein plötzlich gestiegener Speicherbedarf nach einer Codeänderung deutet auf ein Leck, nicht auf echten Bedarf.
4.
Die Node-Version aktualisieren
Ältere Node-Versionen hatten teils niedrigere Standardlimits und ineffizientere Speicherverwaltung. Eine aktuelle LTS-Version von Node kann den Fehler allein durch bessere Voreinstellungen beheben.
5.
Den Build aufteilen oder verschlanken
Lässt sich der Speicherbedarf nicht rechtfertigen, den Build entlasten: Quellcode-Karten (Source Maps) im Produktions-Build abschalten, große Abhängigkeiten aufteilen oder den Vorgang in kleinere Schritte zerlegen, statt nur das Limit immer weiter hochzudrehen.
Häufige Fragen (FAQ)
?Der Rechner hat 32 GB RAM. Warum geht Node der Speicher aus?
Weil Node sich nicht so viel nimmt, wie da ist. Die JavaScript-Engine arbeitet mit einem festen Heap-Limit, das je nach Version bei wenigen Gigabyte liegt – unabhängig vom tatsächlich verfügbaren Speicher. Der Fehler bedeutet: Dieses Limit ist erreicht, nicht dass der Rechner voll wäre.
?Ist das Anheben des Limits die Lösung?
Es ist ein Test, keine Antwort. Mit --max-old-space-size lässt sich der Heap vergrößern, und bei einem großen, legitimen Build ist das völlig in Ordnung. Wächst der Verbrauch aber immer weiter, verdeckt ein höheres Limit nur ein Speicherleck – dann verschiebt man den Absturz, statt ihn zu verhindern.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.