Stabile Knoten-API bei 512 MB RAM. Einen Monat später: PM2 startet alle vier Stunden neu. Wir fügen „max_memory_restart=800M“ hinzu – starten Sie die Schleife während der Mittagsspitze mit vierzig pro Minute neu. Post-Mortem: Globaler „Map“-Cache, indiziert durch Benutzer-ID ohne Räumung, eingeführt mit der Funktionalität „temporäre Sitzungen“ – langsames Leck, in einem zehnminütigen Test unsichtbar.
Der Knoten gibt Speicher nicht aggressiv an das Betriebssystem zurück – heapUsed kann nach einem Garbage Collector fehlschlagen. Bei einem Leck handelt es sich um ein Trendwachstum unter repräsentativer Auslastung, nicht um einen Spitzenwert nach der Bereitstellung. Ein Neustart jede Nacht verbirgt das Problem, bis eines Tages das Intervall nicht mehr ausreicht.
Vor dem Neustart überwachen
Messen Sie, worauf es ankommt:
| Metrisch | Signal |
|---|---|
process.memoryUsage().heapUsed | Trend nach Garbage Collection |
| RSS | Es ist das RSS, das der OOM-Killer beobachtet |
| Verzögerung der Ereignisschleife | Leckage + Last = Latenz der Ereignisschleife |
| Häufigkeit von GC-Pausen | Erhöht sich, wenn der Stapel wächst |
Gängige Werkzeuge:
- Prometheus mit node_exporter und Anwendungsmetriken „/metrics“.
- PM2
pm2 monit,--max-memory-restartgekoppelt mit einer Warnung, wenn der Neustartzähler steigt - APM (Datadog usw.) zur Korrelation von Heap- und langsamen Abfragen
Faustregel: ein geplanter Neustart mit Maske – Legen Sie eine RSS-Benachrichtigung > Grundlinie × 1,5 für eine Stunde fest, bevor Sie einen nächtlichen Cron hinzufügen.
Ein Neustart ohne Diagramm bedeutet, den Krankenwagen ohne Diagnose zu bezahlen.
Heap-Diagnose
Vorgehensweise im Staging, dann in der Produktion außerhalb der Spitzenzeiten:
- Wiederholen Sie eine lange Ladung (k6 für mindestens zwei Stunden).
- Erfassen Sie am Anfang und am Ende einen Heap-Snapshot – „--inspect“ oder „--heapsnapshot-near-heap-limit“ (Knoten 18+).
- Vergleichen Sie in Chrome DevTools (Vergleich) – die Anzahl der Objekte nimmt zu.
- Montieren Sie die Halterungen (Verschluss, Array, Puffer) wieder.
Häufige Ursachen für die Web-API:
- „setInterval“ wurde nie mit „clearInterval“ abgebrochen
- „socket.on“ ohne „removeListener“ dupliziert
- Protokollierungsbibliothek mit Kontextreferenzen
– Globales Objekt „{ [reqId]: largeObject }“ wurde nie gelöscht
Hosting- und Speicherbeschränkungen
In Containern oder Kubernetes tötet das Speicherlimit Node durch SIGKILL ohne ordnungsgemäßes Herunterfahren. Legen Sie die Grenze über den maximalen Heapspeicher plus etwas Spielraum für nativen Code fest – oder beheben Sie das Leck.
Auf VPS wird durch Swap die Leistung ausgeblendet und dann zunichte gemacht – Warnung bei RSS, nicht nur bei der CPU. Ein einzelner Knotenprozess: Das Leck betrifft den gesamten Dienst. Der PM2-Clustermodus behebt das Leck nicht, sondern vervielfacht es auf mehrere Worker.
Vergleichen Sie Node-geeignete VPS-Angebote über das Verzeichnis und den Vergleich. Für die Bereitstellung mit PM2 in Produktion kreuzen.
PM2: Neustart versus Korrektur
„max_memory_restart“: vorübergehend mit einem Prioritätsermittlungsticket akzeptabel.
Nächtlicher Cron-Neustart: tolerierbar, wenn kein bekanntes Leck (Memory Return to OS-Seltsamkeit) – kein Ersatz für eine Korrektur.
Kombinieren Sie max_restarts und exp_backoff_restart_delay, um Neustartschleifen zu vermeiden, die WebSockets mitten in der Spitzenzeit herunterfahren.
The Top: Auto-Reboot ist eine sich anhäufende Schuld
Folgendes verbirgt PM2, wenn alles stabil zu sein scheint.
Teamkultur: Heap-Snapshot vor dem Hinzufügen von max_memory_restart – oder zumindest ein veraltetes Ursachenticket.
Entscheide dich und gehe ohne blinden Fleck voran
Bevor Sie einen Neustart-Cron hinzufügen:
- Sieben-Tage-RSS-Diagramm bei normalem Datenverkehr – erkennen Sie den Trend, nicht isolierte Spitzen.
- Warnung zum PM2-Neustartzähler – nicht nur zur HTTP-Verfügbarkeit.
- Langlasttest im Staging – mindestens zwei Stunden, um ein langsames Leck aufzudecken.
- Beheben Sie die im Snapshot identifizierten Retainer – Karte ohne TTL, Listener, Timer.
- Entfernen Sie den Cron-Neustart, wenn sich die Speicherkurve nach der Korrektur stabilisiert.
Konsultieren Sie PM2-Bereitstellung, um Best Practices für die Überwachung zu finden, und das Verzeichnis, um einen VPS mit genügend RAM auszuwählen, um einen Heap-Snapshot außerhalb der Spitzenzeiten zu erfassen.
Häufig gestellte Fragen
Wie erkennt man einen Node.js-Speicherverlust?
Beobachten Sie die RSS- oder Heap-Verwendung über mehrere Stunden oder Tage hinweg bei stabilem Datenverkehr. Wenn die Kurve nach der Speicherbereinigung ansteigt, ohne abzufallen, liegt wahrscheinlich ein Leck vor. Ein Anstieg und dann ein Abfall ist normal; ein aufsteigendes Plateau ist es nicht.
PM2 max_memory_restart reicht?
Dies ist eine Notlösung – wird vor OOM recycelt, verliert jedoch den Status, verbirgt die Grundursache und kann zu einer Schleife führen. Kombinieren Sie dies mit einer Warnung und einer Heap-Untersuchung, bevor Sie das Problem als gelöst betrachten.
Heapdump in der Produktion?
Möglich außerhalb der Spitzenzeiten mit „--heapsnapshot-near-heap-limit“ (Knoten 18+) oder manuell ausgelöstem „Heapdump“-Modul. Analysieren Sie in Chrome DevTools – vermeiden Sie Spitzenzeiten, ohne die Auswirkungen zu messen.
Klassische Lecks in der Node-Web-API?
Abschlüsse, bei denen Abfragereferenzen erhalten bleiben, Ereignis-Listener, die nicht entfernt werden, Kartencache ohne Lebensdauer, aggregierte Puffer, vergessene Timer – alles hinterlässt eine langsam ansteigende RSS-Kurve.
Die Überwachung der Speicherkurve kostet weniger als ein PM2, das an dem Tag, an dem das Leck den Cron einholt, in einer Schleife neu startet.