vmstatでメモリ・I/O統計を監視する方法｜各列の読み方とボトルネックの見分け方

vmstat は、メモリ・スワップ・ディスクI/O・CPUの状態を1行にまとめて、数秒ごとに表示するコマンドです。「サーバーが重い」と感じたときに vmstat 1 を数十秒眺めるだけで、原因がメモリ不足なのか、ディスク待ちなのか、CPU不足なのかの見当がつきます。この記事では、各列の意味、典型的なボトルネックのパターン、WordPress サーバーでの読み方と記録の残し方を説明します。

基本の使い方

vmstat は多くのディストリビューションで procps（procps-ng）パッケージに含まれており、追加のインストールなしで使えます。

# 1秒間隔で10回表示
vmstat 1 10

# 単位をMBにし、幅を広げて桁ずれを防ぎ、時刻も付ける
vmstat -w -S M -t 5

最初に押さえておきたい注意点が1つあります。1行目は起動してからの平均値で、今の状態ではありません。判断には2行目以降を使います。また、1回きりの値ではなく、数十秒続けて見て傾向をつかむことが大切です。

-S M は表示単位を変えるオプションです。指定しないとKiB単位になり、メモリの大きいサーバーでは桁が多くて読みにくくなります。-w（ワイド表示）を付けると列がずれにくくなります。

各列の意味

procps のバージョンによっては、cpu の区分に gu（ゲスト）などの列が追加されていることがあります（2026年10月現在）。列の並びは手元の man vmstat で確認してください。

メモリの読み方：free の少なさは問題ではない

初めて vmstat を見た人がよく驚くのが、free の小ささです。Linux は空いているメモリをファイルのキャッシュ（cache）に使い、必要になればすぐに解放します。free が少なくても cache が大きければ、メモリには余裕があります。

メモリが本当に足りないかは、次の2点で判断します。

1. si / so が0でない値を出し続けている：メモリが足りず、ディスク上のスワップとの間でページを出し入れしている状態です。これが続くと、ディスクの速度に引きずられて全体が極端に遅くなります
2. free も cache も小さい：キャッシュに回す余裕もない状態です

swpd に値があっても、si / so が0なら、過去に追い出されたページが残っているだけで、今は困っていないことが多いです。

「あとどれだけ使えるか」を知りたいときは、free -h の available 列が目安になります。vmstat の -a オプションを付けると、buff / cache の代わりに inact（非アクティブ）と active（アクティブ）が表示され、すぐに回収できるメモリの量を推し量れます。

I/O の読み方：b と wa と bo

ディスクが詰まっているときは、次の列が同時に動きます。

• b が1以上で続く：ディスクの読み書きを待って止まっているプロセスがある
• wa が高い：CPU に仕事を渡せず、I/O を待っている時間が長い
• bi / bo が大きい：読み書きの量そのものが多い

bi / bo が大きいのに wa が低ければ、ディスクは量をさばけています。逆に bi / bo が小さいのに wa が高い場合は、小さなランダムI/Oが多いか、ディスク自体（あるいはVPSの共有ストレージ）が遅い可能性があります。

なお、si / so が多いときは、スワップが原因で bo / bi と wa も上がります。I/O の問題に見えて、根本はメモリ不足ということがよくあるので、メモリの列を先に確認してください。

デバイスごとの詳細を見たい場合は vmstat -d も使えますが、待ち時間まで見るなら sysstat の iostat -x のほうが向いています。

CPU の読み方：r と us / sy と st

• r が CPU コア数を長く上回る：CPU が足りず、処理が順番待ちになっている。コア数は nproc で確認できる
• us が高い：アプリケーション（PHP、MySQL など）の処理が重い
• sy が高い、cs が非常に多い：プロセスの切り替えやシステムコールが多い。プロセス数が多すぎる設定を疑う
• st が高い：VPS やクラウドで、物理ホストの CPU を他の仮想マシンに取られている。サーバー内の設定では改善しにくい

パターン別の見分け方

数十秒眺めたら、次のように当てはめます。

• メモリ不足：si / so が継続、free と cache が小さい、wa も上がる
• ディスク待ち：si / so は0、b が1以上、wa が高い、bo か bi が大きい
• CPU 不足：r がコア数を上回る、id がほぼ0、wa は低い
• 外部要因：どの列も落ち着いているのにサイトが遅い。外部API、DNS、データベースのロック待ちなど、サーバー資源以外を疑う

WordPress サーバーでよくあるケース

WordPress サーバーでメモリ不足を起こしやすいのは、PHP-FPM のプロセス数の上限（pm.max_children）が搭載メモリに対して大きすぎる場合です。アクセスが集中するとプロセスが上限まで増え、合計メモリが物理メモリを超えてスワップが始まります。

おおまかな目安は、1プロセスあたりのメモリ使用量（RSS）から計算します。

# php-fpm プロセスの平均RSS（MB）を表示する例。プロセス名は環境によって php-fpm8.3 などになる
ps -eo rss,comm | awk '/php-fpm/ { sum += $1; n++ } END { if (n) printf "%d procs, avg %.1f MB\n", n, sum / n / 1024 }'

「PHP に割ける空きメモリ ÷ 平均RSS」が pm.max_children の上限の目安です。MySQL / MariaDB の innodb_buffer_pool_size や OS が使う分を先に差し引いて考えます。設定を変える前にはバックアップを取り、変更後は負荷の高い時間帯に vmstat で si / so が0のままかを確認してください。

メモリ不足が限界を超えると、カーネルの OOM Killer がプロセスを強制終了します。MySQL が突然止まった、というときは journalctl -k | grep -i oom や dmesg で記録を確認します。

記録を残す・簡単な検知を作る

vmstat は今の状態を見る道具で、履歴は残しません。障害の調査中に一時的に記録したいときは、タイムスタンプ付きでファイルへ書き出します。

# 5秒ごとに1時間分（720回）記録する
vmstat -t -w 5 720 > /var/tmp/vmstat-$(date +%Y%m%d-%H%M).log &

スワップの動きだけを簡易的に検知するなら、次のように直近の値を判定できます。列番号は表示形式によって変わるため、-a などを付けた場合は合わせて調整してください。

# 5秒間隔で3回取り、1行目（起動後平均）を除いた2行でsi/so（7・8列目）を確認
vmstat -w 5 3 | tail -n 2 | awk '$7 + $8 > 0 { print "swap activity: si=" $7 " so=" $8 }'

常時の記録や過去の振り返りは、sysstat の sar に任せるのが手軽です。vmstat は「今起きていることを素早く見る」、sar は「過去に何が起きたかを振り返る」と使い分けると、調査がスムーズに進みます。

まとめ

• vmstat の1行目は起動後の平均。2行目以降を数十秒続けて見て判断する
• free が少なくても cache が大きければ問題ない。si / so が続くかどうかでメモリ不足を判断する
• I/O 待ちは b・wa・bi/bo、CPU 不足は r とコア数、VPS では st も確認する
• I/O の問題に見えてメモリ不足が根本のことが多いので、メモリの列を先に見る
• WordPress では PHP-FPM の pm.max_children を平均RSSから見積もり、変更後に vmstat で検証する

• Linuxのsarコマンドでシステム統計を確認する方法
• OOM Killerで止まるWordPressのメモリ設定を見直す方法