メモリを増やす前に残す観測票：使用量・上限・停止時刻を並べる

運営・編集: VPS運用ノート編集部（編集方針）

使用率が高いだけでは、メモリを増やす理由として足りない。何の処理中に、どの上限に達し、何が止まったかを同じ時刻で照合する。

Dockerの数字を同じ物差しにそろえる

Docker statsの公式資料によると、LinuxのCLI表示は使用量からキャッシュ分を差し引く。APIはその計算をせず、総量とキャッシュの情報を返す。cgroupの版によって参照するキャッシュ項目も違う。

したがって、管理画面の値とCLIが違っても、それだけでは測定の誤りとはいえない。計測方法、単位、対象のコンテナ、時刻をそろえる。停止したコンテナはstatsを返さないため、空欄を「0 MiBで動作中」と補わない。資料確認日: 2026年9月14日。

観測票は、処理名から始める

当サイトでは、単発の使用率を書き写す表より、次のような横並びの記録を使う設計にした。下の行は記入欄であり、実測結果ではない。

何も動いていない時の一回だけでは、夜間バッチの余裕は分からない。逆に、短いピークがあっても業務への影響がなければ、その値だけから契約変更を決めることはできない。

自分が管理するコンテナの確認なら、対象名を指定したdocker stats --no-stream コンテナ名で一時点の表示を取れる。これは連続記録ではない。短いピークを取り逃がす場合があるので、必要な観測期間と間隔は処理の長さから決める。

上限とホスト容量は別に見る

Dockerのリソース制約には、メモリ制限と不足時の挙動が説明されている。コンテナ側の上限が原因なら、VPSのメモリだけ増えても、同じ制限で再び止まる可能性がある。一方、制限を外せば必ず解決するわけでもない。ほかのサービスを圧迫しないか確認が必要だ。

• OOMの記録がある: 対象、時刻、設定上限、同時実行を照合する。
• 再起動だけが増えた: 終了理由やアプリのログを見る。すべての再起動をメモリ不足と扱わない。
• 遅いがメモリに余裕がある: CPU、ディスク待ち、外部API待ちなど、別の要因を調べる。
• ホスト全体が苦しい: コンテナ単独の数字に加え、同居する処理とOSの状態を確認する。

共有するログからは鍵や顧客情報を除く。問題を再現するために稼働中のVPSへ無計画な負荷をかける方法は、この観測票の前提にしていない。

契約を変える判断へ渡す

増額の依頼には「使用率が高い」だけでなく、「この処理が、この条件で、上限に達して失敗した。設定や処理量の調整後も必要量が残る」と記録を添える。変更後は、同じ業務条件で再確認する。前後でデータ量や同時実行が違うなら、その差も残す。

変更で何が維持されるかはプラン変更と作り直しへ。料金を比べる前に、停止・データ・IPの扱いを確認する。保守そのものを担えない場合は自己管理の担当範囲を見直す。