CPU使用率が高いときの原因プロセス特定手順｜top・psの見方
「サーバーのCPUがずっと高いままなんだけど」「なんか今日サイト重くない？」——そんな一言で呼ばれて、慌ててサーバーにログインする。監視のグラフを見ると、たしかにCPU使用率が天井近くに張り付いている。でも、そこから先。「じゃあ何がCPUを食っているの？」を突き止めようとして top を叩いた瞬間、数字がびっしり並んだ画面を前に、どこを見ればいいのか手が止まる——。
そんな経験、ありませんか。
CPU使用率が高いという事実だけでは、まだ半分です。大事なのは、どのプロセスが・なぜ食っているのかを落ち着いて特定して、次の一手（止める・待つ・調べる）につなげること。この記事では、CPU使用率が高いときに原因のプロセスを見つけるまでの手順を、top と ps の読み方を中心に、一人運用の目線で順番に整理します。最初から全部を直そうとしなくて大丈夫です。まずは「本当にCPUが原因なのか」を確かめるところから、一緒に見ていきましょう。
結論：CPUが高いと言われたら、①まず全体像を見る（uptimeの load average と、topの CPU 行で%us／%sy／%waのどれが高いか）②犯人を特定する（topを CPU 順に並べ、psで確定させる）③性質を見極める（一時的なバッチか、暴走して張り付いているか、そもそもCPUではなくディスク待ちか）④一次対処と再発防止（止める・優先度を下げる・監視を1本入れる）——の順で進めます。まずは①の「何が高いのか」を分けるところから。
コマンドは Linux を前提にしています。ディストリビューションやバージョン、top の版で表示や項目名が少し異なります。ここを出発点に、本番へ反映する前に検証環境と公式情報で確認してください。
まず「本当にCPUが原因か」を分ける
いきなり「どのプロセスが重いか」を探す前に、まず一段引いて全体を見ます。ここを飛ばすと、「CPUだと思って調べていたら、本当はディスクの待ちだった」という遠回りをしがちだからです。
まず負荷の平均を見る（uptime）
uptime出力の例：
05:44:12 up 42 days, 3:10, 1 user, load average: 4.85, 2.10, 1.42右端の load average（負荷の平均）は、左から順に直近1分・5分・15分の平均です。ざっくり言うと「実行を待っているプロセスがどれくらい溜まっているか」を表します。
見るときのコツは、CPUのコア数と比べること。コア数と同じくらいの値なら「ちょうど使い切っている」状態、コア数を大きく超えていれば「捌ききれずに詰まっている」状態です。コア数は nproc で確認できます。
nprocそして、3つの数字の並び方も手がかりになります。4.85, 2.10, 1.42 のように左（直近）が大きいなら、負荷はいま上がってきている最中。逆に左が小さいなら、山は越えて落ち着いてきた、と読めます。
top の CPU 行で「何が」高いかを見る
次に top を開いて、上のほうにある CPU の1行を見ます。
top%Cpu(s) の行は、こんな並びです（版によって表記は多少違います）：
%Cpu(s): 78.0 us, 8.0 sy, 0.0 ni, 10.0 id, 3.0 wa, 0.0 hi, 1.0 si, 0.0 stここで見たいのは、次の3つです。
us（ユーザー）：アプリケーション（自分たちのプログラムやミドルウェア）がCPUを使っている割合。ここが高ければ、原因は動いているアプリの中にある可能性が高い。sy（システム）：OS（カーネル）の処理が使っている割合。極端に高いときは、システムコールの多い処理や、通信・I/O まわりを疑います。wa（I/O待ち）：CPUが仕事をしているのではなく、ディスクなどの読み書き完了を「待っている」割合。ここが高いなら、犯人はCPUではなくディスクI/Oかもしれません。CPUのプロセスをいくら探しても見つからないときは、まずこのwaを疑ってください。
id（アイドル＝暇な割合）が小さく、us が大きいなら、素直に「アプリがCPUを食っている」ケース。ここまで分かってから、犯人のプロセスを探しにいきます。「CPUが高い」の中身を先に分ける——これが、遠回りを防ぐいちばんの近道です。
犯人のプロセスを特定する（top と ps の見方）
us が高い＝アプリがCPUを食っていると当たりがついたら、どのプロセスかを絞り込みます。
top を CPU 使用率の高い順に並べる
top を起動した状態で P キー（大文字）を押すと、CPU使用率（%CPU）の高い順に並び替わります。上に来ているものが、いまいちばんCPUを食っているプロセスです。
各行で見るのは、主にこの3つです。
%CPU：そのプロセスのCPU使用率。1コアを使い切ると 100% と表示され、複数コアを使う処理だと 200%・300% を超えることもあります（topの既定表示では、コア数×100% が上限のイメージ）。ここが張り付いていれば有力な容疑者です。COMMAND：プロセスの名前。php-fpm／mysqld／nginx／javaなど、心当たりのある名前かどうかを見ます。PID：プロセスの番号。後でpsで詳しく調べたり、止めたりするときに使います。
ps で確定させる（記録にも残せる）
top は刻々と動くので、その瞬間を切り取って記録に残すなら ps が便利です。CPU使用率の高い順に上位を出します。
# CPU使用率が高い順に上位10件（%CPU の降順）
ps aux --sort=-%cpu | head -n 11ps aux の主な列は次の通りです。
%CPU：CPU使用率。ただしpsの%CPUはプロセスが起動してからの平均寄りの値で、topの「今この瞬間」とは少しズレます。「今どれが暴れているか」はtop、「記録として残す・平均を見る」はpsと使い分けると混乱しません。PID：プロセス番号。START/TIME：いつ起動したか／累積でどれだけCPU時間を使ったか。さっき起動したばかりなのに%CPUが高いなら暴走を、ずっと前から動いていてTIMEが異常に大きいなら、じわじわ効いている常駐を疑えます。COMMAND：起動時のコマンドライン。引数まで見えるので、「どのバッチが」「どの設定で」動いているかの手がかりになります。
上位に来たプロセスの PID と COMMAND が分かれば、犯人の名前まではたどり着けました。ここで焦って止める前に、もう一段だけ「性質」を見ておくと、対処を間違えずに済みます。
その負荷の「性質」を見極める
同じ「CPUが高い」でも、正体によって打ち手はまったく変わります。慌てて止めて、大事なバッチを途中で殺してしまった——という事故を避けるためにも、次の3つのどれかを見極めます。
- 一時的な処理（正常なピーク）：夜間バッチ、バックアップ、ログ集計、定期的なインポートなど。決まった時間に上がって、終われば下がるのが特徴です。
psのSTARTが心当たりの時間で、処理内容も業務上必要なものなら、これは「止める」対象ではなく「終わるのを待つ・時間帯をずらす」対象です。 - 暴走・張り付き（異常）：一つのプロセスが
%CPUを長時間占有し続け、いつまでも下がらない。無限ループ、想定外の重いクエリ、外部からの過剰なアクセスなどが原因のことが多いです。こちらは調査・対処の対象になります。 - CPUではなくI/O待ち：先ほどの
%waが高いパターン。プロセス一覧を見てもCPUを食っている犯人がはっきりせず、なのに反応が遅い。この場合はCPUではなく、ディスクやネットワークの待ちを疑い、調べる先を切り替えます。
見極めるときは、時間の軸を足すと分かりやすくなります。top をしばらく眺める、あるいは監視のグラフで「いつから・どんな形で上がったか」を見る。ずっと平らに張り付いているなら暴走を、山なりに上がって下がるなら一時的な処理を、まず疑う。正体が分かれば、次にやることは自然と決まります。
一次対処：あわてて止めない
犯人と性質が分かったら、一次対処です。急いでいるときほど、この順で落ち着いて。
- 正常なピークなら、止めずに待つ／ずらす：必要な処理が重なっているだけなら、無理に止めません。毎回きついなら、実行時間帯を分散させる・重い処理を分割する、といった改善を後日の宿題にします。
- 暴走していて業務に影響が出ているなら、対象だけを落ち着かせる：本当に不要・異常だと確認できたプロセスに絞って対処します。いきなり強制終了（
kill -9）ではなく、まず穏やかな停止を試すのが基本です。止める前に、それが何のプロセスで・止めて安全かを確かめる。共有サーバーで別の人が動かしているものだった、という取り違えを防ぐためです。 - 優先度を下げてしのぐ選択もある：止められないが重い、というときは、
reniceなどでそのプロセスのCPU優先度を下げて、ほかの処理に回りやすくする手もあります（根本解決ではなく、当面の延命として）。 - I/O待ちが原因なら、CPUではなくディスク側を見る：
%waが高かったなら、対処の舞台はCPUではありません。重い読み書きをしているプロセスや、ディスクの空き・性能のほうへ調べる先を移します。
一次対処の目的は、原因の完全解決ではなく、まずサービスを落ち着かせて、腰を据えて調べられる状態を作ることです。ここまで来れば、いちばん怖い「鳴っている最中に手探りで対応する」状態からは抜けられます。
影響：見る順番が決まっていると、何が変わるか
- 「CPUが高い」が「〇〇というプロセスがこういう理由で食っている」に変わり、次に何をすればいいかがはっきりする
%waを先に見る癖がつくと、CPUではないのにCPUを探し続ける遠回りを避けられる- 「正常なピーク」と「暴走」を分けられれば、大事なバッチを誤って止める事故を減らせる
- 特定の手順を残しておけば、自分が不在のときも、誰かが同じ順番で確認・対処できる
放置すると、CPU逼迫は「重い・遅い・たまに落ちる」という形で、忘れたころに戻ってきます。しかも毎回その場の勘で調べていると、対応時間も結果もバラバラになりがちです。逆に言えば、「まず何を・どの順で見るか」を一度決めておけば、同じ場面で慌てることは、ぐっと減ります。
明日やること：まず「見る順番」を1回なぞる1手から
- いちばん止まると困るサーバーで、
uptimeとtopを開き、load average とコア数の関係、%us／%sy／%waのどれが高いかを一度確かめておく（平常時の“ふつう”を知っておくと、異常に気づきやすい）。 topでPキーを押してCPU順に並べ替える操作を、実際に一度やってみる。上位に来るプロセス名（php-fpm／mysqldなど）を目に馴染ませておく。ps aux --sort=-%cpu | headを1回叩いて、その瞬間を記録として残す形を体験しておく。障害時はこれをそのまま貼れば記録になる。- 余力があれば、重要サーバーに CPU使用率（や load average）が一定を超えたら通知する監視を1本入れる。まずは1台でいい。
この流れなら、30分あれば「見る順番の確認」と「平常時の把握」までは終わります。監視の1本は、次にCPUが上がったとき、あなたが呼ばれる前にサーバーが教えてくれる備えになります。
CPU使用率・原因プロセス特定チェックリスト
最低ライン（優先順位つき：これだけで回る） 1) 全体を見る：uptime の load average（コア数と比較）と、top の %us／%sy／%wa を確認する
2) 犯人を絞る：top で P キー、または ps aux --sort=-%cpu | head で上位プロセスを特定する 3) 性質を分ける：一時的なピークか／暴走か／I/O待ち（%wa高）かを見極めてから対処する
余力が出たら拡張
- 重要サーバーに「CPU使用率／load average が閾値超過で通知」の監視を1本入れる
- 定期バッチのCPUピークが重なっていないか、実行時間帯を見直す
- 繰り返し重くなる処理は、クエリや実装の改善を後日の宿題として記録する
免除条件（省略可）
- 使い捨ての検証サーバーや、重くても業務に影響しない一時環境は監視を省略可。ただし「まず何を・どの順で見るか」の手順だけは共有しておく。
確認項目
- CPUが高いと言われたら、まず
uptimeの load average をコア数と比べて見ている -
topの CPU 行で%us／%sy／%waのどれが高いかを分けられる -
%waが高いときは「CPUではなくI/O待ち」を疑える -
topのPキーで CPU 使用率の高い順に並べ替えられる -
%CPUが 1コア=100% で、複数コアだと 100% を超えうると分かっている -
top（今この瞬間）とps（平均・記録）を使い分けられている - 「正常なピーク」と「暴走」を、時間の軸（START・グラフの形）で見分けている
- プロセスを止める前に、何のプロセスで止めて安全かを確かめている
- 重要サーバーに「CPU逼迫で通知」の監視が入っている
よければ、こちらも
CPU使用率は、「サーバーのどこかが逼迫している」サインのひとつです。同じ“重い・遅い・落ちる”を切り分ける手順や、逼迫を前もって拾う監視の考え方も、あわせて型にしておくと落ち着けます。
- 「サイトが重い」の切り分け手順｜どこが遅いかを順番に絞る
- メモリ不足でプロセスが落ちる｜OOMの兆候の見つけ方と一次対処
- 死活監視・外形監視・リソース監視の違い｜最低限の監視設計
- 監視アラートの鳴らしすぎを減らす｜閾値の決め方と運用のコツ
CPUが高いという知らせは、最初はどこから手をつけるか分からず、心細いものです。でも、「まず全体を見て、犯人を絞って、性質を見極める」と順番を決めておくだけで、あの画面いっぱいの数字も、ずいぶん怖くなくなります。 今日は、気になっていたあのサーバーで top を一度開いて、CPUの並びを眺めてみるだけで十分です。平常時の“ふつう”を知っておくことが、次の異常にいち早く気づく力になります。見る順番が身についた時点で、もう対応は前に進んでいます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。