Hohe Next.js-Speichernutzung: So diagnostizieren Sie sie

#Identifizieren Sie den Prozess und die Phase

Notieren Sie die Node- und Next.js-Versionen, den Startbefehl und die Container- oder Dienstgrenzen. Ein nächster Entwicklungsprozess behält Kompilierungstools bei, die den nächsten Start nicht beschreiben. Ein Fehler beim nächsten Build ist wiederum ein anderer Fall.

Lesen Sie das Protokoll vor dem Neustart. Ein V8-Heap-Fehler und ein durch die Speicherbeschränkung des Systems abgebrochener Prozess sind unterschiedliche Signale. Behalten Sie Zeitstempel, PID und Arbeitslast. Ein VPS-weites Diagramm allein kann Next.js keinen Speicher zuordnen.

node --version
npm ls next react react-dom
ps -eo pid,ppid,rss,comm --sort=-rss

#Vergleichen Sie Heap, RSS und Servicespeicher

Process.memoryUsage() meldet Werte einschließlich RSS, HeapUsed, HeapTotal, External und ArrayBuffers in Bytes. Rufen Sie es innerhalb des Bewerbungsprozesses auf, den Sie untersuchen, beispielsweise durch private Instrumentierung. Wenn Sie node -e daneben ausführen, wird nur dieser neue Prozess gemessen.

Wenn heapUsed nach der Erfassung sinkt, während RSS hoch bleibt, stellt dies kein JavaScript-Leck dar. Auch native Zuordnungen, Puffer und Allokatorverhalten verdienen eine Untersuchung. Beobachten Sie bei mehreren Prozessen auch die gesamte Servicegruppe. Halten Sie Diagnoseendpunkte privat.

const timer = setInterval(() => {
  const { rss, heapUsed, external } = process.memoryUsage();
  console.log(JSON.stringify({
    event: "memory-sample",
    pid: process.pid,
    rss, heapUsed, external,
    at: new Date().toISOString()
  }));
}, 10000);
timer.unref();

#Wiederholen Sie eine Arbeitsbelastung, die Wachstum auslöst

Wählen Sie eine verdächtige Route, wiederholen Sie einen identischen Stapel von Anfragen und lassen Sie den Server anschließend beruhigen. Notieren Sie die Werte nach jeder Charge. Ein anfänglicher Anstieg, der ein Plateau erreicht, kann auf eine Modulauslastung oder einen begrenzten Cache hinweisen.

Anhaltendes Wachstum nach vergleichbaren Chargen bedarf einer genaueren Untersuchung. Untersuchen Sie globale Sammlungen pro Benutzer, Caches ohne Ablaufdatum, Abonnements, die aktiv bleiben, und große Objekte, die durch Schließungen zurückgehalten werden. Berücksichtigen Sie abgebrochene Anforderungen und unterbrochene Verbindungen, wenn die Anwendung Antworten streamt.

#Untersuchen Sie den Build-Speicher separat

Wenn der Build fehlschlägt, identifizieren Sie die Phase: Transformation, TypeScript-Überprüfung oder Vorrendern. Das Generieren einer Seite für Tausende von Parametern unterscheidet sich vom Laden einer großen Compiler-Abhängigkeit.

Next.js dokumentiert einen experimentellen Build-Speicher-Diagnosemodus mit Einschränkungen je nach Worker und Build-Engine. Überprüfen Sie die Anwendbarkeit auf Ihre Version, bevor Sie sie verwenden. Reduzieren Sie einen Import- oder Generierungsstapel für einen Zweig und vergleichen Sie das Ergebnis. Durch Erhöhen von --max-old-space-size wird kein RAM erstellt und der Prozess kann näher an die VPS-Grenze heranrücken.

#Erstellen Sie Snapshots für eine Diagnoseinstanz

Mit einem Heap-Snapshot können Sie Objekte und ihre Aufbewahrungspfade untersuchen. Vergleichen Sie Aufnahmen, die an gleichwertigen Punkten in einem Szenario aufgenommen wurden, und untersuchen Sie dann, was nach späteren Stapeln übrig bleibt. Der Verweis, der die Freigabe verhindert, ist wichtiger als die Objektgröße allein.

Die Erfassung kann den Vorgang unterbrechen und erheblichen zusätzlichen Speicher erfordern. Nutzen Sie eine Diagnoseinstanz mit passenden Daten. Snapshots können vertrauliche Anwendungsinformationen enthalten. Halten Sie sie daher vertraulich. Machen Sie den Debug-Port nicht öffentlich verfügbar.

#Überprüfen Sie den Fix mit derselben Arbeitslast

Wiederholen Sie nach dem Fix das Szenario, die Abbrüche und das Leerlaufintervall. Vergleichen Sie Speicher, Fehler und Antwortzeiten. Eine geringere Heap-Nutzung zusammen mit einem Durchsatzeinbruch kann eher einen Kompromiss bei der Sammlung als eine allgemeine Verbesserung widerspiegeln.

Um eine andere Laufzeit wie PRNext auszuwerten, behalten Sie die Methode und Routen bei. Durch das Wechseln der Laufzeiten wird ein unbegrenzter Anwendungscache nicht automatisch behoben. Überprüfen Sie zunächst die Kompatibilität und messen Sie dann den gesamten Dienst.

Erstellen Sie einen SSR-Benchmark mit Inhaltsvalidierung

Bereiten Sie eine PRNext-Testversion für eine Projektkopie vor