実際に実行するアプリに合わせてサイジングしてください。

測定する前に

自分が管理する Linux のテストマシンを、アプリケーションと代表的なデータとともに使用してください。以下のコマンドはリソースを検査するものであり、カーネルを調整したりファイルを削除したりするものではありません。procps と GNU coreutils、および選択したアプリケーションディレクトリを検査する権限が必要です。次を実際のパスに置き換えてください: /srv/my-app 実際のパスに置き換えてください。アプリがまだどこでも実行されていない場合は、開発環境またはステージング環境を使用して初期見積もりを作成し、意図したシステムでその見積もりを再検討してください。

VPS を共有するものを書き出してください: オペレーティングシステム、プロキシ、API、データベース、ワーカー、監視。アセットビルドがそこで実行されるか、バックアップがローカルで圧縮されるか、スケジュールされたタスクがデプロイと重複する可能性があるかを記録してください。静かなアプリケーションプロセスは、高コストなリリースプロセスと共存できます。

利用可能なメモリを読み、プロセスを特定する

free -m
ps -eo pid,comm,rss --sort=-rss | head -n 12

free -m はメビバイトで報告します。次に注目してください: available: スワップせずに新しい作業を支えられる可能性のあるメモリの見積もり。 free だけでは有用な再利用可能メモリを除外してしまいます。したがって、キャッシュだけが RAM を増やす理由にはなりません。参照: free フィールドの定義.

Illustrative selected fields — not an OffVPS measurement
Mem total: 2048 MiB
Mem free:   180 MiB
Mem available: 800 MiB

Illustrative ps rows
  PID COMMAND     RSS
 2100 postgres 393216
 2140 node     184320
  920 caddy     32768

上記のプロセス RSS 値はおおよそ 384、180、32 MiB に対応します。これらはメモリ使用の特定に役立ちますが、すべての RSS 値を合計しても正確なマシン合計にはなりません: 共有ページは複数回カウントされる可能性があり、一部のカーネルコストはプロセス数値の外にあります。レポートを収集する際は、コマンド引数や環境を出力しないでください。シークレットが含まれる可能性があります。 ps マニュアル はそのフィールドとスナップショットの挙動を説明しています。

観察をワークシートに変える

以下の割り当ては、ローカルデータベースと1つのワーカーを持つ小規模な API を例示しています。これらは架空の計画値であり、特定のフレームワークのベンチマークや最低要件ではありません。自分の測定値に置き換え、どの割り当てが同時にピークになる可能性があるかに注意してください。

このワークシートはすでに 1,024 MiB の予算を超えています。2,048 MiB のテスト環境ではこれらの割り当てに対して 676 MiB が残りますが、有用な結果は、アプリが応答性を保ちながら実際の代表的な作業が収まるかどうかです。デプロイの割り当てが支配的な場合は、恒久的なサーバーを拡大するよりも、成果物を別の場所でビルドする方が良い変更かもしれません。合計の横に前提条件を保持してください。

有用な作業中の CPU とスワップを監視する

vmstat 1 10

これを代表的なリクエストバッチ、ジョブ、リリース中に実行してください。最近のインターバルを解釈するときは最初の行を無視してください: 起動からの活動を要約しています。以降の行はサンプリング間隔を表します。 rでの持続的な実行可能作業、 id での低いアイドル時間、および遅いリクエストがそろえば、CPU プレッシャーの調査が正当化されます。繰り返される si/so の活動はスワッピングを示します。スワップの割り当てだけでは現在のプレッシャーを証明しません。 wa と st は自動的な CPU アップグレードではなく文脈が必要です。これらのフィールドは次で定義されています: vmstat.

アプリケーションでの応答時間も記録してください。遅い外部 API やデータベースクエリは、CPU がほとんどアイドルのままリクエストを待たせることがあります。1つの変更後に同じワークロードを繰り返し、どの変更が役立ったかを把握してください。負荷テストは自分が管理するシステムのみを対象とし、他のユーザーを妨げないレートと停止条件にしてください。

ディスクの増加と転送を別々に予算化する

df -h /srv/my-app
df -i /srv/my-app
du -sh /srv/my-app

df パスを含むファイルシステムを説明し、他のディレクトリと共有されるスペースを含みます。 df -i はサポートされている場合に inode 使用量を確認します。多数の小さなファイルは、バイト容量より先に inode を枯渇させる可能性があります。 du はアクセス権限を条件に、選択したツリーを見積もります。これらは異なる問いであるため、合計が一致する必要はありません。参照: df と du.

現在のデータベース、アップロード、ログ、アプリケーション成果物、およびローカルのバックアップステージングスペースをリストアップしてください。前のリリースと並んでリリースに必要なスペースを追加し、次のレビュー期間にわたる増加を見積もってください。たとえば、毎日 100 MiB の新しいアップロードは、レプリカやバックアップの前に 30 日間で約 3,000 MiB を追加します。結果をカタログと比較するときは、10進 GB と2進 GiB を一貫してラベル付けしてください。

転送については、例示的な 20 kB の応答を 50,000 回送信すると、応答ペイロードは約 1 GB になります。アップロード、静的ファイル、プロトコルオーバーヘッド、バックアップトラフィックを追加してください。その算術はボリュームを見積もるものであり、スループットや同時ユーザーではありません。サービスがトラフィックをどのようにカウントし、超過をどのように処理するかを確認してください。

次のアクションを選び、確認する

• 通常のピーク時に利用可能メモリが低い: 主な消費者を調査し、より大きなメモリ予算をテストしてください。
• 持続的な CPU プレッシャーを伴う遅いリクエスト: ビジーパスをプロファイリングし、同じワークロードを使用して CPU の変更を比較してください。
• ディスク使用量の増加: 何かを削除する前に、責任のあるディレクトリと保持ポリシーを特定してください。
• リソースは快適に見えるがアプリが遅い: 依存関係、クエリ、リクエストパスを調査してください。

ワークロードの説明、サンプル時刻、単位、次回レビュー日を含めてワークシートを保存してください。大幅なリリース、データ増加、ワーカーの追加後に再確認してください。それらの観察から構成を選択してください。プラン名がリクエスト容量を保証するものではありません。次を続けてください: メモリとディスクの警告を読む または 最初の API リソースシナリオ.