LinuxのCPU・メモリ・I/Oボトルネックをリアルタイムで特定する方法

まず実行する──5秒間隔で継続監視する基本コマンド

vmstatは引数なしで実行すると起動時からの平均値を1行だけ表示します。実務ではインターバルと回数を指定して継続観測するのが基本です。

# 5秒ごとに継続表示（Ctrl+C で終了）
vmstat 5

# 5秒ごとに10回だけ表示（ログ取りに向く）
vmstat 5 10

# タイムスタンプ付きで記録（後で時系列を追いやすい）
vmstat -t 5 10

出力例は次のようになります。最初の1行は起動時からの累積平均なので、リアルタイムの状況は2行目以降で判断してください。

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 1205432  51240 823640    0    0   136    22  412  731  4  2 91  3  0
 0  0      0 1205200  51248 823648    0    0     0     4  388  614  1  0 99  0  0
 0  0      0 1205200  51256 823648    0    0     0     6  401  628  0  0 100  0  0

vmstatはprocpsパッケージ（Debian/Ubuntu）またはprocps-ng（RHEL/AlmaLinux系）に含まれており、ほぼすべての主要ディストリビューションで追加インストール不要です。

出力フィールドの意味を押さえる

procs（プロセス状態）

rはCPUを待つ実行待ちプロセス数、bはI/O完了待ちなどで割り込み不可状態のプロセス数です。rがnprocで確認できるCPUコア数を継続的に上回っていれば、CPU不足のサインです。

memory（メモリ使用状況、単位はkB）

swpdがスワップ使用量、freeが未使用のメモリ量です。buffはブロックデバイスのバッファ、cacheはページキャッシュに使われているメモリです。Linuxはメモリをキャッシュに積極的に活用するため、freeが少なくても即座に問題にはなりません。swpdと後述のswapグループの動きをセットで見るのが基本です。

swap（スワップのI/O、単位はkB/s）

si（swap in）がディスクからメモリへの読み込み、so（swap out）がメモリからディスクへの追い出しです。どちらか一方でも0以外が続く場合はメモリ不足の赤信号です。

io / system / cpu

bi/boはブロックデバイスへの読み書き（kB/s）、in/csは毎秒の割り込み回数とコンテキストスイッチ回数です。cpuグループのus・sy・id・wa・stは合計が常に100になります。waがI/O待機、stはハイパーバイザーに奪われたCPU時間（VM環境のみ）を示します。

CPUボトルネックの診断パターン

CPUが詰まっているときの典型的な出力は次のようになります。

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  0      0 3200000  12000 450000    0    0     0     2 1200 8500 78 12  8  2  0
 7  0      0 3190000  12000 450000    0    0     0     0 1150 9200 80 15  5  0  0

チェックポイントは次の通りです。

• rがCPUコア数を継続的に超えている
• us＋syが80〜90%以上でidがほぼ0
• waは低い（I/O待ちではなく純粋なCPU不足）

usが高ければアプリケーションのロジック側、syが高ければシステムコールやカーネル処理が原因です。syが20%を超える場合はperf topでカーネル内の処理を絞り込むのが有効です。

クラウドインスタンスや仮想マシン環境ではst（steal time）も見逃せません。stが5%を超える場合、ホスト側のCPU競合でゲストが本来のCPU時間を奪われています。アプリを最適化しても改善しない性能低下の原因がここにある場合があり、インスタンスタイプの見直しやホストの分散が解決策になります。

メモリ・スワップ不足の診断パターン

メモリが逼迫しているときの出力例です。

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  1 512000  45000   2000  80000  200  150   850   180  890 1200 30  8 20 42  0
 3  2 524288  32000   1800  75000  350  280  1200   320  920 1400 25 10 10 55  0

注目すべき点は次の通りです。

• swpdが0より大きく、かつ増加し続けている
• si・soが継続的に0より大きい
• 連動してwa（I/O待機）も上昇する（スワップI/Oが原因）
• freeとcacheが刻々と減っている

si/soが高い状態が続く「スワップ・スラッシング」に陥ると、サーバーがほぼ応答しなくなります。この状態を検知したら、まずfree -hでメモリの全体像を確認し、続けてps aux --sort=-%mem | head -20でメモリを大量消費しているプロセスを特定してください。

なおswpdの値は過去にスワップを使った痕跡が残る場合があります。現在進行形でスワップI/Oが発生しているかどうかはsiとsoの値で判断するのが正確です。

I/Oボトルネックの診断パターン

ディスクI/Oがボトルネックになっている状況では次のような出力になります。

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  4      0 2100000  35000 680000    0    0  8500  6200  680 1100 15  5 18 62  0
 1  3      0 2090000  35200 682000    0    0  9200  7100  720 1050 12  4 20 64  0

• waが20〜40%以上に達している
• b（I/O待ちプロセス数）が継続的に増えている
• bi・boが大きい一方、si・soは0（スワップではなくディスクI/Oが原因）

ディスクI/Oの詳細を掘り下げるにはiostat -xz 5を使います。デバイスごとの%util（使用率）とawait（I/O待ち時間ms）が確認できるため、どのデバイスが詰まっているかを特定できます。

# 詳細なディスクI/O統計（sysstat パッケージが必要）
# Debian/Ubuntu: apt install sysstat
# RHEL/AlmaLinux: dnf install sysstat
iostat -xz 5

ログとして記録して後から分析する

障害対応中はリアルタイムで監視するだけでなく、ファイルに残しておくと事後の原因究明に役立ちます。

# タイムスタンプ付きで60秒間（5秒×12回）ファイルに記録
vmstat -t 5 12 >> /var/log/vmstat_$(date +%Y%m%d_%H%M%S).log

# バックグラウンドで30分間（5秒×360回）記録
vmstat -t 5 360 >> /var/log/vmstat_monitor.log &

# sar があれば過去のリソース統計も参照できる
# systemd タイマーまたは /etc/cron.d/sysstat で自動収集される場合が多い
sar -u 5 10   # CPU使用率を5秒間隔で10回表示

ある運用現場では、深夜の定期バッチ処理後にレスポンスが悪化するという問題が繰り返し発生していました。vmstat -t 5の出力をcronで5分ごとにファイルへ記録する仕組みを導入したところ、waとbiの急増がバッチ終了直後に集中していることが判明し、バッチの書き込みタイミングを分散させることで問題を解消できました。

継続的な監視が必要な場合はsysstatパッケージのsarやPrometheus＋node_exporterを使った長期収集も検討してください。vmstatは問題発生時にすぐ手が届く診断ツールとして、sarやiostatは傾向分析用として使い分けるのが実務的なアプローチです。