深夜の障害対応でこの状況に陥ると、焦りで頭が真っ白になる人は少なくありません。
この記事では、Linuxサーバーの高負荷が発生した際に CPU・メモリ・ディスクI/O を順番に切り分ける手順 を、コマンドの実行例と出力の読み方とともに解説します。
RHEL 9.4 / Ubuntu 24.04 LTS で動作確認済みです。
この記事のポイント
・まず top/uptime でロードアベレージの傾向を掴む
・CPU 高負荷なら top の %us/%sy/%wa の内訳で方向を絞る
・メモリ不足は free -h の available 欄とスワップ使用量で判断する
・ディスク待ちは iostat -x で %iowait と %util を確認する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ「順番に調べる」のが正解なのか
サーバーが重くなる原因は大きく3つに分類できます。CPU 使用率の急騰、メモリ枯渇によるスワップ多用、そしてディスクへの過負荷（I/O 待ち）です。これらは症状が似ていて、「とにかく top を開く」だけでは混乱するケースがあります。現場で長年使われてきた鉄則は、「ロードアベレージ → CPU → メモリ → ディスクI/O」の順で仮説を絞ることです。それぞれの確認コマンドと見方を、以下で順を追って説明します。
Step 1: ロードアベレージで全体の傾向を把握する
1. uptime でロードアベレージを確認する
まず最初に実行するのがuptime です。$ uptime 23:41:05 up 12 days, 14:38, 2 users, load average: 8.52, 6.14, 3.88
load average: 8.52, 6.14, 3.88 は直近 1分・5分・15分の平均値です。・1分値 > 15分値：負荷は 上昇中（急騰している）
・1分値 < 15分値：負荷は 落ち着きつつある
ロードアベレージの目安はコア数に依存します。4コアの CPU なら 4.0 が「飽和」の目安です。上の例は 8コア相当の環境で 8.52 が出ているため、現時点で完全に飽和していると判断できます。
2. コア数を確認する
ロードアベレージの数値を解釈するには、CPU コア数が必要です。$ nproc 8
Step 2: CPU 使用率の内訳を読む
3. top で CPU の何が高いかを判断する
ロードアベレージが高い場合、次はtop を起動して CPU 使用率の内訳を確認します。$ top top - 23:41:12 up 12 days, 14:38, 2 users, load average: 8.52, 6.14, 3.88 Tasks: 245 total, 3 running, 242 sleeping, 0 stopped, 0 zombie %Cpu(s): 72.3 us, 5.1 sy, 0.0 ni, 12.6 id, 9.8 wa, 0.0 hi, 0.2 si, 0.0 st PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18243 apache 20 0 1245820 512344 12384 R 58.2 6.3 5:14.21 php-fpm 22017 mysql 20 0 8324568 3.5g 512244 S 23.1 44.1 32:18.02 mysqld 891 root 20 0 356788 8940 7124 S 0.8 0.1 0:01.44 rsyslogd
・us（user）：ユーザープロセスによる CPU 使用率。高い場合はアプリが CPU を占有している
・sy（system）：カーネルの処理。高い場合はシステムコールやカーネル処理が多い
・wa（iowait）：ディスクI/O 待ち。5%を超えたらディスク問題の疑い
・id（idle）：アイドル率。これが低いほどCPUが逼迫している
上の例では
us=72.3% が最大の原因で、php-fpm が 58.2% を占有しています。アプリ側の問題と判断できます。4. %wa が高い場合はディスクI/O が原因
%wa（iowait） が 10% 以上の場合はディスクの問題が疑われます。後述の Step 4 に進んでください。Step 3: メモリ・スワップの状態を確認する
5. free -h でメモリ残量とスワップを確認する
$ free -h total used free shared buff/cache available Mem: 15Gi 13Gi 112Mi 842Mi 1.9Gi 902Mi Swap: 4.0Gi 3.2Gi 823Mi
・available（利用可能）：バッファ/キャッシュを解放した場合に使える残量。
free の列より実態を反映している・Swap used：スワップ使用量が大きいほどメモリ不足が深刻
上の例では
available = 902Mi、Swap が 3.2Gi 使用中です。物理メモリが枯渇してスワップに逃げている典型的なメモリ不足の状態です。6. vmstat 1 5 でスワップの出入りを確認する
free の数値だけでなく、スワップのページイン・ページアウトが発生しているか も確認します。$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 4 3 3276800 98212 12044 1954320 842 1120 1024 3840 1458 2840 68 8 14 10 0 5 2 3276800 96104 12044 1956320 644 980 824 3200 1288 2540 65 10 15 10 0 3 4 3277056 94208 12044 1956320 988 1204 1108 4120 1568 3040 70 7 13 10 0
si（スワップイン）と so（スワップアウト）が継続的に 0 以外の場合、メモリ不足によるスワップスラッシングが発生しています。この状態ではサーバーのレスポンスが大幅に低下します。7. メモリを多く使っているプロセスを特定する
# RES（実物理メモリ）の降順でプロセスを表示 $ ps aux --sort=-%mem | head -10 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND mysql 22017 23.1 44.1 8324568 3670956 ? Sl Jun15 32:18 /usr/sbin/mysqld apache 18243 58.2 6.3 1245820 512344 ? R 23:30 5:14 php-fpm: worker apache 18244 32.1 5.8 1245820 489120 ? R 23:31 3:02 php-fpm: worker
Step 4: ディスクI/O の負荷を切り分ける
8. iostat -x でディスクI/O 状況を確認する
top の %wa が高い場合や、ディスクI/O が疑われる場合は iostat を使います。$ iostat -x 1 3 Linux 5.14.0-427.13.1.el9_4.x86_64 2026/06/17 _x86_64_ (8 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 68.30 0.00 7.80 9.80 0.00 14.10 Device r/s w/s rkB/s wkB/s %util await aqu-sz svctm sda 18.2 245.4 548.6 12140.8 94.2 42.3 9.8 3.8 sdb 0.1 0.2 2.4 1.6 0.2 1.2 0.0 1.0
・%util：デバイスの使用率。80% 以上で飽和状態（上の例: sda が 94.2%）
・await：I/O リクエストの平均待ち時間（ms）。10ms 以上は要注意（上の例: 42.3ms）
・aqu-sz：I/O キューのサイズ。1 を大きく超えるとキューが詰まっている
上の例では sda が完全に飽和しています。これが
%wa = 9.8% の原因です。9. iotop でI/O を発生させているプロセスを特定する
iostat でディスクが飽和していると確認できたら、次はどのプロセスがI/O を発生させているかを特定します。# root 権限が必要 $ sudo iotop -o -d 1 Total DISK READ: 48.52 M/s | Total DISK WRITE: 112.34 M/s Current DISK READ: 48.52 M/s | Current DISK WRITE: 112.34 M/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 22017 be/4 mysql 12.44 M/s 89.12 M/s 0.00 % 82.31 % mysqld 18243 be/4 apache 8.24 M/s 9.44 M/s 0.00 % 12.40 % php-fpm: worker
-o オプションで実際にI/O が発生しているプロセスのみを表示します。上の例では mysqld が書き込みの大半を占めています。切り分け結果に応じた対処の方向性
| 確認した症状 | 原因の仮説 | 次に取る行動 |
|---|---|---|
| us が高い・特定プロセスの %CPU が高い | アプリ起因のCPU 負荷 | 該当プロセスのログ確認・設定見直し・再起動検討 |
| si/so が継続的に 0 以外・スワップ多用 | メモリ不足 | メモリ大消費プロセスの特定・増設またはキャッシュ設定調整 |
| %wa が高い・%util が 80% 超 | ディスクI/O 飽和 | iotop で書き込みプロセス特定・クエリ最適化・SSD 交換検討 |
| sy が高い | カーネル・システムコール多発 | strace で特定プロセスのシステムコールを追跡 |
| all 低いのにロードが高い | プロセス数過多・ネットワーク待ちの可能性 | netstat/ss でコネクション数確認・プロセス状態(D状態)確認 |
トラブルシュート: D 状態のプロセスがある場合
ロードアベレージが高いのに CPU 使用率が低い場合、プロセスがディスク/ネットワークのI/O 待ちで「D（Uninterruptible Sleep）」状態に入っていることがあります。# D 状態のプロセスを確認 $ ps aux | awk '$8 == "D" {print $0}' mysql 22017 23.1 44.1 8324568 3670956 ? D Jun15 32:18 /usr/sbin/mysqld # D 状態のプロセス数をカウント $ ps aux | grep -c '^.\{8\}D' 3
dmesg | tail -30 でカーネルエラーも確認してください。# カーネルエラーを確認（直近のI/O エラー・ハードウェアエラー等） $ dmesg | tail -30 [1234567.890123] end_request: I/O error, dev sda, sector 12345678 [1234568.012345] blk_update_request: I/O error, dev sda, sector 12345679
smartctl -a /dev/sda でディスクの健康状態を確認してください。本記事のまとめ
Linuxサーバーの高負荷を切り分ける手順を整理します。| ステップ | コマンド | 確認ポイント |
|---|---|---|
| 1. ロードアベレージ確認 | uptime |
コア数と比較して飽和度を判断 |
| 2. CPU 内訳を確認 | top |
%us / %sy / %wa の内訳を読む |
| 3. メモリ・スワップ確認 | free -h / vmstat 1 5 |
available 残量と si/so の継続発生を確認 |
| 4. ディスクI/O 確認 | iostat -x 1 3 |
%util・await の値で飽和を判断 |
| 5. 原因プロセス特定 | ps aux --sort=-%cpu / iotop -o |
CPU・I/O それぞれの犯人を特定 |
| 6. D 状態確認 | ps aux | awk '$8 == "D"' / dmesg |
ハードウェア障害・NFS 問題を除外 |
Linuxサーバーの監視・パフォーマンス管理をさらに体系的に学びたい方は、下記の関連記事も参考にしてください。
・Linux ポート確認の全コマンド
高負荷の切り分けができると、次は「仕組みから理解する」ステージへ
サーバーが重くなった時に焦らず切り分けられるのは、Linuxのリソース管理の仕組みを正しく理解しているからです。コマンドの使い方だけでなく、CPU・メモリ・ディスクの関係を体系的に身につけることで、障害対応のスピードが格段に上がります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Rocky Linuxサーバーを構築する手順｜最小インストールから初期設定・Webサーバー公開まで
- この記事の属するカテゴリ：Linuxtips・Linuxトラブルシューティングへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます