Das Node.js-Memory-Leak-Playbook — Heap-Snapshots, clinic.js und die vier Patterns, die wir immer wieder finden

Node.js-Memory-Leaks wirken oft erschreckend und sind es meistens nicht. Dieselben vier Patterns tauchen in Audit nach Audit auf: ein Map/Set, der unbegrenzt wächst, ein Closure, das einen unerwartet großen Parent-Scope hält, Event-Listener, die angehängt, aber nie entfernt werden, und ein In-Process-Cache ohne Eviction-Policy.

Dies ist das Diagnose-Playbook, das wir auf Kunden-Node-Services anwenden, die anfangen, Woche für Woche Speicher zu fressen.

Heap-Snapshots — die einzige Diagnose, die nicht Raterei ist

import v8 from 'node:v8';
import fs from 'node:fs';
 
process.on('SIGUSR2', () => {
  const file = `/tmp/heap-${Date.now()}.heapsnapshot`;
  v8.writeHeapSnapshot(file);
  console.log('wrote', file);
});

Senden Sie SIGUSR2 an den Prozess, holen Sie einen Snapshot, wiederholen Sie nach 30 Minuten Traffic, diffen Sie die beiden im Memory-Tab der Chrome DevTools. Die Retained-Objects-Spalte sagt Ihnen genau, was wächst.

Der vollständige Beitrag behandelt:

• Die vier Patterns und wie jedes im Heap-Snapshot-Diff erscheint
• clinic.js doctor und clinic flame für CPU + Memory zusammen
• --inspect und Chrome DevTools für Live-Profiling im Nicht-Prod
• Leak-Detection gegen Ihre eigenen Services in CI vor Produktion laufen lassen
• Die cgroups + OOMKiller-Lesart, wenn der Leak trotzdem in Produktion landete
• Wann der „Leak" tatsächlich V8s Young Generation ist, die nicht schnell genug sammelt (das ist kein Leak)

Melden Sie sich, wenn Ihr Node-Service still gewachsen ist und niemand weiß warum.