Linuxサーバーを監視していると、vmstatのb（Blocked）が じわじわ、あるいは継続的に増え続けるケースがあります。
CPU使用率は低い、ロードアベレージも一見高くない。 それでもレスポンスが悪化し、処理が詰まっている―― このような状況の正体は、ほぼ例外なくI/O待ちによるプロセス停滞です。
本記事では、
- b（Blocked）が何を意味しているのか
- なぜ増え続けるのか
- どこを見て、どうなれば「解決」と判断できるのか
を、実運用でそのまま使える切り分け手順として解説します。
b（Blocked）とは何か？
vmstatに表示される b は、
ディスクI/Oやストレージ応答待ちでブロックされているプロセス数
を表します。
つまり b が増えるということは、
- CPUは仕事をしたくても
- ディスクやストレージからの応答待ちで
- プロセスが「止められている」
状態です。
ここで重要なのは、
bが増える = CPUが忙しいではない点です。
むしろ典型的な症状は、
- CPU idle が高い
- ロードアベレージが微妙に上がる
- レスポンスが体感で遅い
という「分かりづらい遅さ」です。
b（Blocked）が増え続ける典型的な原因
① ディスクI/O待ち（最頻出）
最も多い原因は、ディスクI/Oの詰まりです。
- ログ大量書き込み
- バックアップ処理
- DBのフルスキャン・チェックポイント
これらが走ると、I/O待ちが発生し、 プロセスはディスク応答待ちでbに積み上がります。
この状態ではCPUは暇なので、 「負荷は低いのに遅い」という誤解を招きます。
② swap-in / swap-out によるI/O待ち
メモリが逼迫し、swapが使われ始めると、
- メモリ → ディスク
- ディスク → メモリ
というI/Oが発生します。
このswap I/O待ちによっても、 プロセスはブロックされ、bが増加します。
特に注意すべきなのは、
- swap使用量が少量でも
- si / so が継続的に出ている
ケースです。 これは「swapが原因の遅延」が始まっているサインです。
③ ストレージ遅延（SAN / 仮想環境）
物理ディスクに余裕があっても、
- SANストレージの混雑
- 仮想環境の共有ストレージ遅延
によってI/O応答が遅れ、bが増えることがあります。
この場合、OS上では原因が見えにくいのが特徴です。
実践的な切り分け手順
Step1：vmstatで全体像を確認
vmstat 1注目ポイントは以下です。
- b が継続的に増えているか
- wa（I/O wait）が発生しているか
- si / so が断続的または継続的に出ていないか
b + wa + si/so が揃っている場合、 I/O起因である可能性は極めて高いです。
Step2：iostatでディスクの詰まりを確認
iostat -x 1以下を重点的に見ます。
- %util が高止まりしていないか
- await が異常に高くないか
重要なのは、
%utilが低くてもawaitが高い場合、体感遅延は発生する
という点です。
Step3：iotopでブロック犯人を特定
iotop -oここで、
- どのプロセスがI/Oを占有しているか
- 周期的に暴れている処理はないか
を確認します。
ログ・バックアップ・DBが犯人であるケースが非常に多いです。
どうなれば「解決」と判断できるのか
対処後、以下の状態になっていれば解決と判断できます。
- b が 0 〜 微小で安定
- wa がほぼ 0
- si / so が発生しない
- 体感レスポンスが回復
重要なのは、
一時的にbが下がることではなく、安定して増えないこと
です。
まとめ
- b（Blocked）は「CPUではなくI/O待ち」のサイン
- 増え続ける場合、ディスク or swap が原因
- vmstat → iostat → iotop の順で切り分ける
- bが安定して0付近になれば解決
bを正しく読めるようになると、 「CPU idleが高いのに遅い」というトラブルの正体が 一気に見えるようになります。
