topコマンドで確認してもどのコアに問題があるのか分からない」「シングルスレッドのアプリが1コアを使い切っているはずなのに、CPU全体の平均で見ると大したことないように見える」
Linuxのマルチコアサーバーでは、CPU全体の平均使用率だけを見ていると問題を見落とすことがあります。
topコマンドが表示する「%CPU合計」は全コアの平均値であるため、特定のコアだけに負荷が集中するケースでは原因を特定できません。この記事では、コア別CPU使用率をリアルタイムで確認できる
mpstatコマンドの実践的な使い方を解説します。sysstatのインストールから出力項目の読み方、高負荷コアを特定するトラブルシュート手順まで、実機出力例とともに説明します。RHEL 9 / Rocky Linux 9 / Ubuntu 24.04 LTSで動作確認済みです。この記事のポイント
・mpstat -P ALL 1 でコア別CPU使用率を1秒ごとに確認できる
・sysstatパッケージをインストールするだけで即使える（RHEL/Ubuntu両対応）
・%iowait高 → I/O待ち、%irq・%soft高 → ネットワーク割り込み集中が疑われる
・sar・iostatと同パッケージで、コア別の過去データ分析も可能
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
topコマンドだけでは気づけないCPU問題とは
現代のLinuxサーバーは4コア、8コア、16コアが当たり前です。topコマンドを起動すると「%Cpu(s): 28.5 us」のように全コアの平均使用率が表示されますが、この数値は個々のコアの状態を隠してしまいます。たとえば8コアのサーバーで1つのコアだけが100%になっている場合、全体平均では12.5%にしかなりません。「CPUはまだ余裕がある」と判断してしまいがちですが、そのコアに処理を依存しているアプリケーションは応答が遅延します。
コア別の確認が特に重要になるのは次のような場面です。
・シングルスレッドアプリの高負荷：PHPのリクエスト処理、バッチスクリプト、レガシーなCアプリは1コアしか使えないため、そのコアだけが100%になる
・ネットワークIRQの偏り：NICの割り込み（IRQ）がCPU0だけに集中すると、ネットワーク高負荷時にCPU0の%irq・%softが急上昇する
・仮想環境のvCPU争奪：ハイパーバイザー上のVMでは、特定のvCPUに対してスティールタイム（%steal）が発生することがある
これらを見分けるには、コア別にCPU使用率を分解して表示できるツールが必要です。それが
mpstat（multiprocessor statistics）です。なお、CPUのソケット数や物理コア数・論理コア数を事前に把握したい場合は、dmidecodeでハードウェア情報を取得するとBIOSレベルの詳細なCPUトポロジーを確認できます。
sysstatのインストールとmpstatの基本的な使い方
mpstatはsysstatパッケージに含まれています。sysstatにはsar（過去の統計を記録・閲覧するツール）やiostat（ディスクI/O統計）も含まれており、システム性能監視のセット品です。1. sysstatパッケージのインストール
RHEL 9 / Rocky Linux 9 / AlmaLinux 9の場合はdnfでインストールします。# RHEL系（RHEL 9 / Rocky Linux 9 / AlmaLinux 9） [root@websvr01 ~]# dnf install sysstat -y # インストール完了後、sarによる定期収集サービスを有効化する [root@websvr01 ~]# systemctl enable --now sysstat # mpstatのバージョン確認 [root@websvr01 ~]# mpstat -V sysstat version 12.5.4
aptでインストールします。# Ubuntu / Debian系 $ sudo apt install sysstat -y # インストール確認 $ mpstat -V sysstat version 12.6.0
2. mpstatの基本構文と出力確認
オプションなしでmpstatを実行すると、全CPUの合計統計が1行で表示されます。[root@websvr01 ~]# mpstat Linux 5.14.0-362.8.1.el9_3.x86_64 (websvr01.example.internal) 2026/08/16 _x86_64_ (8 CPU) 14:23:05 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 14:23:05 all 6.42 0.00 1.83 0.21 0.01 0.12 0.00 0.00 0.00 91.41
websvr01.example.internal）とCPU数（8 CPU）が表示されています。all行は全コアの平均値です。この時点では使用率が低く、問題はなさそうに見えます。しかし、この平均値だけでは特定コアの高負荷を見逃す可能性があります。3. 出力項目の読み方
mpstatの各列の意味を把握しておくことが重要です。・%usr：ユーザー空間（アプリケーション）のCPU使用率。高い場合はアプリ側の処理が原因
・%nice：nice値が設定されたプロセスのCPU使用率
・%sys：カーネル空間のCPU使用率。高い場合はシステムコールやコンテキストスイッチが多い
・%iowait：I/O完了待ちでCPUがアイドル状態になっている割合。ディスクI/Oボトルネックの指標
・%irq：ハードウェア割り込みの処理に使ったCPU使用率。ネットワーク高負荷時にCPU0で上昇しやすい
・%soft：ソフトウェア割り込みの処理に使ったCPU使用率。%irqと合わせて確認する
・%steal：ハイパーバイザーに奪われた時間（仮想環境のみ）。高い場合は物理ホストのCPUリソース不足
・%idle：CPUが何もしていない時間の割合。これが低いほど負荷が高い
実務でよく使うオプション
1. -P ALLでコア別使用率を一覧表示する
-P ALLオプションを付けると、全コアの使用率を個別に表示します。高負荷コアの特定に最も使う構文です。[root@websvr01 ~]# mpstat -P ALL Linux 5.14.0-362.8.1.el9_3.x86_64 (websvr01.example.internal) 2026/08/16 _x86_64_ (8 CPU) 14:31:12 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 14:31:12 all 14.62 0.00 2.14 0.18 0.01 0.08 0.00 0.00 0.00 82.97 14:31:12 0 97.82 0.00 2.18 0.00 0.00 0.00 0.00 0.00 0.00 0.00 14:31:12 1 1.22 0.00 0.61 0.00 0.03 0.12 0.00 0.00 0.00 98.02 14:31:12 2 0.98 0.00 0.49 0.00 0.02 0.09 0.00 0.00 0.00 98.42 14:31:12 3 1.05 0.00 0.52 0.00 0.01 0.06 0.00 0.00 0.00 98.36 14:31:12 4 0.91 0.00 0.45 0.00 0.01 0.07 0.00 0.00 0.00 98.56 14:31:12 5 1.11 0.00 0.55 0.00 0.01 0.08 0.00 0.00 0.00 98.25 14:31:12 6 0.88 0.00 0.44 0.00 0.00 0.08 0.00 0.00 0.00 98.60 14:31:12 7 0.94 0.00 0.47 0.00 0.01 0.07 0.00 0.00 0.00 98.51
all行では14.62%に過ぎませんが、CPU0だけが%usr=97.82%でほぼ100%稼働しています。これが「全体平均は低いのに応答が遅い」という現象の典型的な原因です。2. インターバルと繰り返し回数を指定する
mpstatはオプションなしだと起動時点からの累積平均を1回表示するだけです。リアルタイム監視にはインターバル（秒）と繰り返し回数を指定します。# 1秒ごとに5回、コア別使用率を表示する（現場で最もよく使う構文） [root@websvr01 ~]# mpstat -P ALL 1 5 # 3秒ごとに繰り返し（Ctrl+Cで停止） [root@websvr01 ~]# mpstat -P ALL 3
3. 特定のCPUコアだけを監視する
-Pオプションにコア番号を指定すると、そのコアだけを表示できます。CPU0に問題があると分かっている場合など、出力を絞り込みたいときに便利です。# CPU0のみを1秒ごとに確認する [root@websvr01 ~]# mpstat -P 0 1 # CPU0とCPU1を同時に監視する [root@websvr01 ~]# mpstat -P 0,1 1
高負荷コアを特定するトラブルシュート手順
mpstat -P ALL 1で高負荷なコアが見つかったら、次の手順で原因を掘り下げます。1. %usrが特定コアで高い場合 ～ シングルスレッドプロセスを疑う
CPU0だけ%usr=95%以上で他のコアは低い、という状況はシングルスレッドプロセスの高負荷を示します。ps auxでCPU使用率順に並べて犯人プロセスを特定します。# CPU使用率順（降順）でプロセスを表示する [root@websvr01 ~]# ps aux --sort=-%cpu | head -10 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND www-data 18234 97.3 2.1 892340 87124 ? R 14:28 143:12 php-fpm: worker process root 892 0.3 0.1 35428 4208 ? Ss Jul01 2:15 /usr/sbin/sshd -D ...
2. %iowaitが高い場合 ～ ディスクI/Oボトルネックを確認する
%iowaitが10%を超えると、CPUがディスクのI/O完了を待機している時間が多いことを示します。iostatコマンドで具体的なデバイスの状況を確認します。# iostatでディスクデバイスのI/O待ちを確認する（1秒ごと3回） [root@websvr01 ~]# iostat -x 1 3 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 12.34 0.00 248.00 0.00 82432.00 664.77 23.84 96.13 0.00 96.13 3.89 96.40
%utilが90%を超えており、await（I/O待ち平均時間：ms）も高い場合はディスク自体が処理限界に達しています。3. %irqや%softが高い場合 ～ ネットワーク割り込みの偏りを確認する
CPU0だけ%irqや%softが高い場合、NICの割り込みがCPU0に集中しているケースがあります。/proc/interruptsでIRQごとのコア別処理数を確認します。# NICのIRQ処理数をCPUコア別に確認する [root@websvr01 ~]# grep eth0 /proc/interrupts 29: 824901234 0 0 0 0 0 0 0 IR-PCI-MSI 524288-edge eth0 # 数字の列がCPU0～CPU7の処理数。CPU0（824901234）だけが極端に多い
irqbalanceサービスを有効化するか、/proc/irq/N/smp_affinityを手動設定します。4. %stealが高い場合 ～ 仮想環境のリソース不足を確認する
クラウドやVMware上のLinuxで%stealが5%を超える場合、物理ホストのCPUリソースが不足してハイパーバイザーに処理時間を奪われています。アプリケーション側での対処は難しく、プランのアップグレードやvCPUの見直しが必要になります。mpstatを使ったトラブルシュートのまとめ
| mpstatで見る指標 | 高い場合の意味 | 次の調査コマンド |
|---|---|---|
| 特定コアの%usr が高い | シングルスレッドプロセスの高負荷 | ps aux --sort=-%cpu | head -10 |
| 複数コアの%usr が高い | マルチスレッドアプリの全コア占有 | ps aux --sort=-%cpu | head -10 |
| %iowait が高い | ディスクI/Oボトルネック | iostat -x 1 5 |
| CPU0の%irq・%soft が高い | NIC割り込みの集中 | grep eth0 /proc/interrupts |
| %steal が高い（VM環境） | 物理ホストのCPUリソース不足 | クラウドのメトリクスコンソール確認 |
| %sys が高い | カーネル処理・コンテキストスイッチ過多 | vmstat 1 5 でcs列を確認 |
本記事のまとめ
mpstatコマンドの基本から実務でのトラブルシュート手順まで解説しました。・
mpstat -P ALL 1 5 がコア別CPU使用率確認の基本構文・
topの全体平均では気づけない「1コア100%問題」を可視化できる・%usr・%iowait・%irq・%soft・%stealそれぞれが何を意味するかを把握しておくことが重要
・高負荷コアを見つけたら
ps aux --sort=-%cpu や iostat で原因プロセス・デバイスを特定する【注意】インターバルなしの実行は累積平均なので使い方に注意
mpstatをオプションなしで実行すると、OSが起動してから現在までの累積平均が表示されます。「今まさに高負荷なのかどうか」をリアルタイムで確認したい場合は、必ずmpstat -P ALL 1のようにインターバルを指定してください。インターバルなしの出力は「現時点の瞬間値」ではないため、高負荷の瞬間を見逃す要注意ポイントです。マルチコア環境が当たり前になった今、CPUの使われ方を「コア単位」で把握する習慣が、障害対応のスピードを大きく左右します。
mpstatはインストールして即使えるシンプルなツールです。普段の定期確認にぜひ取り入れてみてください。
高負荷の切り分けができたら、次はサーバー全体のトラブル対応スキルを体系的に固めませんか？
CPU負荷の原因をコア単位で特定できるのは、Linuxの内部構造を体系的に理解しているエンジニアだけです。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：audit2allowコマンドでSELinuxの拒否エラーを解消する方法｜カスタムポリシーモジュールの作成手順
- この記事の属するカテゴリ：Linuxtips・Linuxトラブルシューティングへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます