アップグレード前にメモリとディスクの警告を読んでください。

文脈を伴う小さなベースラインを取得する

運用するアプリケーションを検査する権限を持つ Linux アカウントを使用してください。ここでのコマンドは状態を検査するものであり、ファイルを削除したりストレージのサイズを変更したりはしません。一部のディレクトリやジャーナルには昇格されたアクセスが必要です。置き換えてください /var/lib/field-api, /opt/field-api と /opt/first-api 実際のアプリケーションパスに置き換え、結果を解釈する前にそれらのパスが存在することを確認してください。

時刻、現在のリリース、およびアクティビティ(通常のトラフィック、アップロード、レポートジョブ、またはデプロイビルド)を記録します。同等のアクティビティ中に再度測定します。無関係な2つのスクリーンショットは、健全なマシンを一貫性がないように見せることがあります。ユーザーがすでに影響を受けている場合は、最初の有用な手がかりを取得してください アプリケーション障害ガイド 一度に複数の変更を行う前に。

利用可能なメモリを確認し、次にワークロードを調査する

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

において free、利用可能メモリはスワップなしで新しいアプリケーションに使用できる量を見積もります。これは再利用可能なキャッシュを考慮するため、完全に未使用の「free」メモリとは異なる問いに答えます。参照してください upstream free マニュアル. Linux はファイルキャッシュにメモリを使用します。大きなキャッシュだけではリークの証拠にはなりません。 カーネルメモリの概要 は、キャッシュとアプリケーションメモリが共存する理由を説明しています。

例示的な測定値であり、サーバー測定ではありません: 小さなホストには約 1.9 GiB の使用可能メモリがあり、80 MiB が空き、850 MiB が利用可能です。空きの数値が低いだけではアップグレードを正当化しません。レポート中に利用可能メモリが繰り返しゼロ近くまで低下し、リクエストが遅くなり、関連する割り当てまたはメモリ不足のメッセージが表示される場合、その複合的な証拠は調査に値します。

「 ps コマンドはプロセスの RSS を KiB 単位で、大きい順に表示します。RSS は常駐メモリを表し、排他的所有権の完全な会計ではありません。共有ページは複数のプロセスに現れることがあります。すべての RSS の数値を足し合わせて、その結果を正確なホスト使用量として扱わないでください。 upstream ps リファレンス は RSS と並べ替えを定義しています。プロセス名と、ワークロード終了後にそのフットプリントが以前のレベルに向かって戻るかどうかを記録します。

使用中のスワップは以前のアクティビティを反映している可能性があり、それ自体では現在の圧力を証明しません。また、ホスト容量とサービスまたはコンテナの制限を区別してください。制限されたプロセスは、ホストにまだ利用可能なメモリがある間に失敗することがあります。VPS のサイズを増やす前に、設定された制限と失敗時刻を確認してください。カーネルの proc ファイルシステムリファレンス は、これらの観察の背後にあるメモリフィールドを文書化しています。

実際に容量を圧迫しているファイルシステムを見つける

df -h / /opt/first-api
df -i / /opt/first-api

最初のコマンドは、それらのパスを含むファイルシステムの空き容量を報告します。2番目は inode を報告します。inode はファイルとディレクトリに必要なファイルシステムレコードです。多数の小さなファイルを含むワークロードは、バイト容量が残っていても inode を使い果たす可能性があります。マウントと両方の種類の容量を確認し、VPS 全体のサイズだけを唯一の数値として使用しないでください。参照してください GNU df マニュアル.

別のマウントされたボリューム上のパスは、ルートファイルシステムとは独立して容量を圧迫する可能性があります。逆に、一覧表示された2つのパスが同じファイルシステムに属する場合、それらの利用可能容量は加算されません。ファイルシステムの予約、クォータ、ストレージ層も、アプリが書き込める内容に影響する可能性があります。表示された単一のパーセンテージでは、増加の所有者を特定できません。

増加をログ、アップロード、または成果物に帰属させる

sudo du -xhd1 /var/lib/field-api
sudo du -xhd1 /var/log
sudo du -xhd1 /opt/field-api
sudo journalctl --disk-usage

GNU du 各ディレクトリ下の割り当て済み容量を見積もります。ここで -x は別のファイルシステムへの侵入を避け、 -h は読みやすい単位を使用し、 -d1 は表示する深さを制限します。大きなツリーはスキャンに時間とディスクアクティビティを要する場合があります。権限エラーは、表示が不完全であることを意味します。参照してください GNU du マニュアル. journal コマンドは、アクティブおよびアーカイブされたファイルを含む journal ストレージを報告します。これは次によって文書化されています journalctl.

最大のディレクトリをその目的と比較します:

• ログ: 繰り返されるエラーが量を増やしたか、ローテーションは設定されているか？
• アップロード: 保持されたユーザーファイルは予想どおりに増えているか、放棄された部分的なアップロードは考慮されているか？
• リリース成果物: 古いビルドがロールバックポリシーを超えて蓄積していないか？
• データベースファイル: データベース自身のツールが増加とメンテナンスの必要性を説明しているか？

不慣れなデータベースディレクトリを削除したり、広範なコンテナボリュームのクリーンアップを調査手順として使用しないでください。まず所有権、保持要件、復元可能なコピーを特定します。もし df とディレクトリの合計が大きく食い違う場合は、マウント境界、アクセスエラー、削除後も開かれたままのファイルを経験豊富な運用者と確認してください。表示されているファイルを繰り返し削除しても、占有されている容量を見落とす可能性があります。

測定値を具体的な次のアクションに変える

例示的なケース: available memory stays comfortable, but an upload directory grows by roughly 400 MiB on each of two observed days. The filesystem has about 2 GiB available. Dividing remaining space by that short-term growth suggests only about five days at the same rate, before allowing operating headroom. That is a planning estimate, not a forecast or a safe deadline to wait until; uploads and temporary work may arrive unevenly.

次のアクションは、アップロードの保持と予想される需要を確認し、正当化される場合は追加ストレージを計画し、行動するのに十分早い段階でアラートを設定することです。より多くの RAM はこの発見に対処しません。別のケースでは、デプロイビルドが配信が小さいままの間に一時的なメモリピークを生むことがあります。ビルドを VPS から移す方が、ランタイムを恒久的に拡大するよりも有用な場合があります。

正当化された変更の後、同じ測定と1つのアプリケーションアクションを繰り返します。容量が実際に利用可能で、意図したデータがまだ機能することを確認してください。削除とサイズ変更は、赤い数値への自動応答ではなく、復旧手順を伴う計画的な操作として維持します。使用してください リソース予算ガイド を、実証された必要性を設定の選択肢に変えるために、そして練習してください 復元 を、クリーンアップや移行に依存する前に。