Linuxメモリ不足・高負荷の確認手順｜free・top・vmstat・ps・OOM
Linuxが重い、CPU使用率が高い、メモリ不足が疑われるときに、負荷・メモリ・swap・プロセス・OOMログを順番に確認して原因を切り分けます。
このページの目的
「サーバーが重い」をCPUだけの問題と決めつけず、load average、CPU、メモリ、swap、I/O待ち、個別プロセス、OOMのどこに異常があるかを分けて確認します。
最初にやること
uptime、free -h、topで全体像を確認し、継続観測が必要ならvmstat 1 5、原因プロセスの候補はpsで絞ります。
関連するLinux障害調査ガイド
journalctlでエラーを確認する
OOMやサービス異常など、現在・前回起動のログを時刻とUnitで絞ります。
ログを確認 → ディスクNo space left on deviceを切り分ける
メモリではなくディスク容量・inode不足が原因の場合はこちらで確認します。
容量を確認 →最短の確認順
最初からプロセス停止やキャッシュ削除をせず、全体負荷 → メモリ → CPU → swap/I/O → 個別プロセス → OOMログの順で事実を残します。
1. uptimeでload averageを確認する
uptimeには1分・5分・15分のload averageが表示されます。load averageはCPU使用率そのものではなく、Linuxでは実行可能状態のタスクに加えて割り込み不能スリープ中のタスクも含むため、CPUだけでなくI/O待ちなどでも上がることがあります。
topやvmstatと組み合わせます。2. freeでメモリ使用量を確認する
free -hではtotal、used、free、buff/cache、available、swapを確認します。Linuxは空きRAMをキャッシュにも利用するため、free列が小さいだけでメモリ不足とは判断しません。対応している環境ではavailableを、swapやOOMの有無と合わせて見ます。
| 見る項目 | 確認のポイント |
|---|---|
available | 新しいアプリが利用できるメモリ量の目安。極端な低下が継続していないか確認 |
buff/cache | ファイルキャッシュ等を含む。大きいだけで異常とは限らない |
Swap | 使用中かどうかだけでなく、実際にswap in/outが継続しているかをvmstatで確認 |
3. topでCPU・メモリ・プロセスを確認する
topではCPU全体、load average、メモリ、swap、各プロセスを同時に確認できます。CPU使用率が高い場合でも、us・sy・waなど、どこで時間を使っているかを分けます。
usが高い：ユーザー空間の処理負荷を確認syが高い：カーネル処理、割り込み、システムコール増加などを確認waが高い：ストレージ等のI/O待ちを疑い、ディスクI/Oの追加調査へ- 特定プロセスだけ高い：PID、起動コマンド、ログ、直前の変更を確認
topの項目やキー操作は実装・バージョンで差があります。共有時は画面だけでなくコマンドや時刻も記録します。
4. vmstatで継続的な状態を確認する
vmstatはrun queue、メモリ、swap、I/O、CPU状態を時系列で確認するのに便利です。最初の行は起動後平均などを反映する場合があるため、1秒間隔などで複数回取得した後続行を中心に見ます。
| 代表項目 | 見るポイント |
|---|---|
r | 実行待ちタスクの目安。継続して増えているか |
si / so | swap in / swap out。継続的に値が出ているか |
wa | I/O待ち時間の割合。高止まりしていないか |
us / sy / id | ユーザー、システム、idleのCPU時間 |
5. swap使用状況を確認する
swapが使われていること自体は即異常ではありません。過去に退避されたページが残っているだけの場合もあります。vmstatのsi/soが継続して発生している、応答時間が悪化している、availableが低い、といった複数の材料で判断します。
swapoffはRAMへページを戻すため、余裕のない環境では状況を悪化させる可能性があります。実施前に影響と空きメモリを確認してください。6. CPU・メモリを使っているプロセスを絞る
RSSはそのプロセスが現在RAM上に持つメモリ量を見る材料ですが、共有ページなどがあるため、単純合計だけで実消費量を断定しないようにします。プロセス名だけでなくPID、実行ユーザー、起動時刻、ログ、親プロセスも確認します。
7. OOM Killerが動いたか確認する
プロセスが突然終了した場合は、OOM Killerによる終了を確認します。OOMログがあれば「メモリ不足だった」で終わらず、どのcgroup・プロセス・制限下で起きたか、直前のメモリ推移、サービス設定を合わせて確認します。
8. 既存環境・古いツールで確認するとき
メモリ・負荷調査ではコマンド名そのものが大きく置き換わった領域ではありませんが、procps/procps-ngやカーネルの世代で表示項目が異なることがあります。新しい表示だけを前提にせず、利用環境の出力に合わせます。
| 確認 | 現在よく使う例 | 既存環境での注意 |
|---|---|---|
| メモリ全体 | free -h | -hやavailableがない古い環境ではfree -mと/proc/meminfoを併用 |
| 負荷・プロセス | top / ps | 列名・並び・sort対応が異なる場合があるためmanや--helpで確認 |
| 過去の傾向 | 監視基盤・sar | sarはsysstatの導入・事前収集が必要。未収集の過去データは後から取得できない |
古い環境だからコマンドを排除するのではなく、「その環境で何が取得できるか」を確認して読み替えるのがこのサイトの方針です。
確認結果から次へ進む
| 確認結果 | 次の調査 |
|---|---|
CPUのusが高く特定プロセスが突出 | アプリログ、処理内容、スレッド数、直前の変更を確認 |
syが高い | システムコール、ネットワーク、ストレージ、カーネル側の負荷を追加調査 |
waが高い | ディスクI/Oやストレージ遅延を調査。容量不足とは別問題として確認 |
available低下＋swap in/out継続 | メモリ需要、プロセスRSS、cgroup制限、swap設計を確認 |
| OOMログあり | 対象PID/cgroup、メモリ上限、直前の増加、再発条件を確認 |
| 負荷は正常だが接続だけ遅い | Linuxネットワーク疎通・接続確認へ |
| ディスク容量が逼迫 | Linuxディスク使用量確認へ |