Next.js は VPS でどれくらいの RAM を必要としますか?

#ビルド、アイドル、ロードを分離する

ビルドはソース コードを変換し、事前にページを生成できます。アイドル状態のサーバーは、ランタイムとロードされたモジュールを保持します。負荷がかかると、複数のレンダリング、ネットワーク呼び出しと応答が同時にアクティブになる可能性があります。これら 3 つの状態を個別に測定します。

CI がビルドを実行するとき、そのピークは実稼働 VPS のサイズを直接決定しません。同じサーバーがサイトを構築してサービスを提供する場合は、その期間中に両方のサーバーの予算を立てます。古いリリースと新しいリリースの間で展開が重複しているため、テストする別のシナリオが追加されます。

#適切なプロセスを測定する

JavaScript ヒープはノードのメモリの一部にすぎません。 RSS には、ネイティブ割り当てを含む常駐プロセス ページが含まれます。 Linux では、PSS は共有ページを比例的に割り当て、プロセス ツリーを比較するときに役立ちます。

systemd サービスの場合は、cgroup メモリも観察します。 PSS とは異なる独自の会計処理を使用してグループをカバーします。メトリクスを記録し、実行間で一貫性を保ちます。 1 つのワーカーだけを測定すると、親、他のワーカー、ネイティブ コンポーネントが欠落します。

systemctl show my-next-app.service -p MemoryCurrent -p MemoryPeak
ps -eo pid,ppid,rss,comm --sort=-rss

#ルートとトラフィックのピークを測定する

数回アクセスして共通パスをロードした後、アイドル状態のメモリを観察します。次に、動的ページ、API、および高価なルートに負荷を徐々に増加させます。応答コンテンツを検証する: 軽量のエラー ページは、障害を隠しながら優れたスループットを生み出すことができます。

ピーク時のメモリ、レイテンシ、エラー、同時実行数を記録します。アプリケーションがセッションに依存している場合は、認証されたトラフィックを含めます。匿名のホームページ トラフィックでは、顧客のダッシュボードが説明されない場合があります。短期間の実行は出発点であり、数週間にわたる安定性の証拠ではありません。

#サーバー全体の予算

オペレーティング システム、プロキシ、データベース、アプリケーションを追加し、ピーク時や展開に備えたヘッドルームを追加します。ターゲット サーバーまたは代表的な環境からの測定値を使用します。メモリ制限により境界が保護されます。アプリケーションに十分なスペースを保証するものではありません。

仮説の例: 2,048 MiB から、システムと共有サービス用に 500 MiB を予約し、次にピークと展開の重複用に 400 MiB を予約します。これで、アプリケーション用に 1,148 MiB が残ります。これらの値は計算を説明するものであり、Next.js の最小値または普遍的な推奨値ではありません。それらを実際の測定値に置き換えてください。

#ベンチマークとその構成を読み取る

PRNext 対 Next.js キャンペーンでは、小規模 VPS の通常の SSR ページは、PRNext には 113.88 MiB PSS を、Next.js には 101.38 MiB PSS を使用します。他のマシンに 2-CPU のバジェットがある場合、値は 117.50 と 173.30 MiB になります。ランキングはコンテキストによって異なります。

これらの結果は、識別された PRNext 0.1.18-alpha 候補、フィクスチャ アプリケーション、および短いウィンドウを説明します。アプリケーション、そのビルド、または最終リリースのアーカイブは測定されません。睡眠は別の状態です。睡眠は非アクティブな労働者の記憶を解放し、覚醒コストを追加します。

ベンチマーク構成とデータを読む

アイドルメモリとウェイクアップコストを理解する

#実際のボトルネックから判断する

十分なメモリがあっても、飽和した CPU によるレイテンシの増加を防ぐことはできません。 CPU は、保持されたオブジェクトやデータベースのメモリ不足を修正しません。リクエストが遅くなるとパフォーマンスが低下するリソースを探します。

変更するたびに同じワークロードを繰り返します。同等の作業を行ってもメモリが安定せずに増加し続ける場合は、保持率を調査してください。ピークが正当な場合は、ビルドが実行される場所、プロセス数、または利用可能な容量を再検討します。

高い Next.js メモリ使用量を診断する