Speicherverbrauch und Memory Leaks in Node.js überwachen

Für Node.js-Entwickler können Memory Leaks zum echten Albtraum werden – und das Erwachen ist nicht so einfach wie ein Aufschrei in der Nacht. Je länger diese Leaks unentdeckt bleiben, desto länger zieht sich der böse Traum hin.

Heißt konkret: CPU- und Speicherauslastung, Load Average und Antwortzeit einer Anwendung mit Memory-Leak-Bugs steigen kontinuierlich, bis die CPU 100 % erreicht – danach reagiert der Dienst nicht mehr. Das sind typische Symptome, wenn eine Anwendung unter einem Memory Leak leidet.

Bist du als Entwickler davon betroffen, lies weiter: Hier erfährst du, wie du diese Symptome angehst und wie du Speicherverbrauch und Memory Leaks in Node.js-Anwendungen überwachst.

Was ist ein 'Memory Leak' in Node.js?

Einfach gesagt ist ein Memory Leak ein Problem, bei dem eine Anwendung einen Speicherblock allokiert, ihn aber nicht wieder freigibt – oder bei dem der Node.js Garbage Collector ihn nicht bereinigen konnte.

Naja, so in etwa ...

Was ist Garbage Collection in Node.js?

Zunächst müssen wir beim Thema Memory Leak den Garbage Collector ins Spiel bringen. Ganz einfach gesagt: Der Garbage Collector ist ein automatischer Mechanismus, der Speicher von nicht mehr verwendeten Objekten zurückgewinnt.

Im ersten Zyklus ("mark") markiert der Garbage Collector ungenutzte Objekte zur Löschung. Im zweiten Zyklus ("sweep") wird der Speicher freigegeben.

Ein Beispiel für eine App mit Memory Leak

Für diesen Leitfaden habe ich eine einfache Express.js-Anwendung erstellt, in der jede Anfrage ein leak-Array über die Laufzeit hinweg wachsen lässt – und so den Dienst verlangsamt. Dieses leak-Array wird nirgends manuell geleert, und die Garbage Collection wirkt sich nicht auf global deklarierte Variablen aus. 

Memory Leaks mit Node Inspector und Chrome DevTools erkennen

Um Node Inspector zu nutzen, müssen wir unsere App im Inspect-Mode starten, und in CLI TypeScript:

node --inspect index.js

Dein Script sollte dann mit der Inspect-Option im DevTools/Devices-Tab erscheinen. Klicke auf Inspect, damit Chrome DevTools sich an das Node-Skript anhängt. Uns interessieren hier vor allem der Memory-Tab und die Heap-Snapshot-Option.

3 Snapshots von Memory Leaks in Node.js

Um zu testen, ob unsere Anwendung ein Memory Leak hat, nehmen wir 3 Heap-Snapshots. Der erste direkt nach dem Start des Servers; der zweite nach einem Benchmark mit 1000 Requests an unseren Server und der dritte nach einem weiteren Benchmark mit 1000 Requests.

Der zweite Snapshot nach dem ersten Benchmark mit 1000 Requests kann als Warnsignal dienen, wenn der Heap gewachsen ist. Also machen wir den letzten Snapshot nach dem zweiten Benchmark: So lässt sich bestätigen, ob die Anwendung ein Memory Leak hat.

Um die Ursache zu finden, wähle den dritten Snapshot aus, klicke auf die Vergleichsoption und vergleiche ihn mit dem ersten Snapshot. So lassen sich seit dem Serverstart neu erstellte Objekte und Daten identifizieren.

Im letzten Schritt schauen wir uns diese Objekte genauer an und suchen nach Objekten mit gleicher Allokationsgröße. Durch diese Untersuchung lassen sich die Memory Leaks in unserer Anwendung auffinden und beheben.

Fazit – Kenne deine Tools

Wenn du auf bewährte Bibliotheken setzt, ist das Beheben eines Node.js-Memory-Leaks meist deutlich einfacher als das Aufspüren. Entscheidend ist ein gutes Verständnis der Garbage Collection in den DevTools sowie der anderen Tools, die du beim Entwickeln nutzt. Mit den verschiedenen Debuggern, Leak-Catchern und Tools zur Erstellung von Nutzungsdiagrammen kannst du Leaks gezielt isolieren – und sorgst so dafür, dass deine Software schneller und effizienter läuft.

Bei Startup Development House sind wir zugegeben ziemlich erfahren im Umgang mit Node.js – und darin, auftretende Probleme zu lösen. Wenn du als angehender Entwickler etwas von dieser Expertise gebrauchen kannst, melde dich gern unter hello@start-up.house