高い Next.js メモリ使用量: 診断方法

メモリが増加し、サイトの速度が低下し、プロセスが再起動されます。ヒープ制限を引き上げる前に、何がいつ増加したかを確認してください。原因としては、ビルド、キャッシュ、大きな応答、または到達可能なままのオブジェクトが考えられます。

このガイドは再現可能な調査に従っています。使用率が高いだけではリークは確立されず、サーバーの測定値はブラウザー タブのメモリから分離されている必要があります。

プロセスとフェーズを特定する

ノードと Next.js のバージョン、起動コマンド、コンテナーまたはサービスの制限を記録します。次の開発プロセスでは、次回の開始を記述していないコンパイル ツールが保持されます。次回のビルド中に失敗する場合は、また別のケースになります。

再起動する前にログを読んでください。 V8 ヒープ エラーとシステムのメモリ制限により強制終了されたプロセスは別の信号です。タイムスタンプ、PID、ワークロードを保持します。 VPS 全体のチャートだけでは、メモリを Next.js に帰すことはできません。

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

ヒープ、RSS、サービス メモリを比較する

process.memoryUsage() は、rss、heapused、heapTotal、external、arrayBuffers などの値をバイト単位で報告します。調査しているアプリケーション プロセス内で、たとえばプライベート インストルメンテーションを通じて呼び出します。ノード -e を同時に実行すると、その新しいプロセスのみが測定されます。

RSS が High のままで収集後に heapused が低下した場合、JavaScript リークは確立されません。ネイティブ割り当て、バッファー、およびアロケーターの動作も調査する価値があります。複数のプロセスの場合は、サービス グループ全体も観察します。診断エンドポイントを非公開にしておきます。

インストルメンテーション.node.js
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();

成長を引き起こすワークロードを繰り返す

疑わしいルートを選択し、同じリクエストのバッチを繰り返し、その後サーバーが安定するようにします。各バッチの後に値を記録します。プラトーに達する初期の上昇は、モジュールの読み込みまたは境界付きキャッシュを反映している可能性があります。

同等のバッチを使用した後も持続的に成長するかどうかについては、より詳細な調査が必要です。ユーザーごとのグローバル コレクション、有効期限のないキャッシュ、アクティブなままのサブスクリプション、クロージャによって保持される大きなオブジェクトを調べます。アプリケーションが応答をストリーミングする場合は、キャンセルされたリクエストと中断された接続が含まれます。

ビルドメモリを個別に調査する

ビルドが失敗した場合は、変換、TypeScript チェック、またはプリレンダリングの段階を特定します。数千のパラメータのページを生成することは、大規模なコンパイラ依存関係をロードすることとは異なります。

Next.js は、ワーカーとビルド エンジンに応じた制限付きの実験的なビルド メモリ診断モードを文書化しています。使用する前に、お使いのバージョンへの適用性を確認してください。ブランチ上のインポートまたは生成バッチを削減し、結果を比較します。 --max-old-space-size を増やしても RAM は作成されず、プロセスが VPS の制限に近づく可能性があります。

診断インスタンスでスナップショットを取得する

ヒープ スナップショットを使用すると、オブジェクトとその保持パスを検査できます。シナリオ内の同等の時点で取得されたキャプチャを比較し、その後のバッチ後に何が残っているかを調査します。リリースを妨げる参照は、オブジェクトのサイズだけよりも重要です。

キャプチャするとプロセスが一時停止し、大量の追加メモリが必要になる場合があります。適切なデータを含む診断インスタンスを使用します。スナップショットにはアプリケーションの機密情報が含まれる可能性があるため、非公開にしておいてください。デバッグ ポートを公に公開しないでください。

同じワークロードで修正を検証する

修正後、シナリオ、キャンセル、アイドル間隔を繰り返します。メモリ、エラー、応答時間を比較します。スループットの低下に伴うヒープ使用量の低下は、全体的な改善ではなく、コレクションのトレードオフを反映している可能性があります。

PRNext などの別のランタイムを評価するには、メソッドとルートを保持します。ランタイムを切り替えても、無制限のアプリケーション キャッシュは自動的に修正されません。まず互換性を確認してから、サービス全体を測定します。

コンテンツ検証を備えた SSR ベンチマークを構築する

プロジェクトのコピーで PRNext トライアル版を準備する

出典と詳細情報

ブログに戻る