ディスクI/Oが遅いときの調べ方：iostat / vmstat でボトルネックを特定する

ディスクI/Oが遅いときの調べ方：iostat / vmstat でボトルネックを特定する
読了時間: 約10分 難易度: 中級

この記事で解決できること

  • 「サーバが重い」「レスポンスが遅い」の原因が ディスクI/Oかどうか を切り分けられます
  • iostat / vmstat を使って CPU待ちなのか、ディスク詰まりなのか を判断できます
  • 「何が起きているか分からない状態」から脱出できます

結論（最短ルート）

ディスクI/Oを疑うときの最短手順はこれ。

  1. CPUが暇なのに遅い？ → iostat -xz 1
  2. I/O待ちが多い？ → %iowait を確認
  3. 書き込み詰まり？ → await / svctm / %util を見る
  4. 本当にディスクが原因か？ → vmstat 1 で全体を見る

前提（対象環境）

  • OS：Ubuntu
  • サーバ触り始めた新人〜実務初期
  • root or sudo 権限あり
  • 物理サーバ / VM / クラウド（EC2等）すべて対象

1. ディスクI/Oが遅いとは何か（誤解しやすい点）

結論: ディスクI/O遅延はアプリの待ち・ログ書き込み詰まり・DB・バックアップなど複数原因がありCPU%だけ見ると必ず見誤る。

「ディスクが遅い」は、実際には次のどれかです。

  • アプリが ディスクの応答待ち
  • ログ書き込みが詰まっている
  • DB / Docker / バックアップがI/Oを食っている
  • CPUは暇だが I/O待ちで止まっている

CPU%だけ見ていると、必ず見誤ります。

2. iostat を使う準備（入っていない場合）

結論: iostatはsysstatパッケージに含まれるためsudo apt install sysstatでインストールしてから使用する。

$ sudo apt update
$ sudo apt install -y sysstat

3. まずは全体を見る（iostat -xz）

結論: iostat -xz 1で1秒ごとに詳細表示しI/O負荷があるデバイスとその規模を把握するのが最初の一手。

$ iostat -xz 1

オプションの意味：

  • -x：詳細表示（必須）
  • -z：0行を省略（見やすく）
  • 1：1秒ごとに更新

4. 重要指標の読み方（ここが核心）

結論: %iowait20%超・%util80%超・await10ms超が同時に起きればディスクI/Oがボトルネックとほぼ確定できる。

4-1. %iowait（CPU側）

  • 10%以上：I/O待ちが目立つ
  • 20%以上：ほぼ確実にディスクI/Oがボトルネック

CPUは仕事をしたいが、ディスク待ちで止まっている状態。

4-2. %util（ディスク側）

  • 70%以下：余裕あり
  • 80〜90%：詰まり始め
  • 100%張り付き：完全に飽和

100%張り付き＝これ以上処理できない

4-3. await（待ち時間）

  • 数ms：正常
  • 10ms超：遅い
  • 50ms超：体感で分かるレベル
  • 100ms超：事故

レスポンス悪化の直接原因になりやすい。

4-4. r/s w/s（読み書き量）

  • どちらが多いかで 読み詰まりか、書き詰まりか を判断
  • ログ肥大・DB書き込みは w/s が跳ねる

5. よくあるパターンと判断

結論: CPU低いが遅い・CPUもI/Oも高い・%util低いのにawaitが高いの3パターンで原因の方向性が変わる。

パターンA：CPUは低いが遅い

  • %iowait 高い
  • %util 高い

典型的なディスクI/O詰まり

パターンB：CPUもI/Oも高い

  • %user / %system 高い
  • %iowait も高い

重い処理＋ディスク書き込みの合わせ技

パターンC：%util低いのに遅い

  • %util 低
  • await 高

ストレージ自体が遅い（ネットワークストレージ、EBS等）

6. vmstat で全体像を掴む（必須）

結論: vmstat 1でbカラム（I/O待ちプロセス数）とwaが増えていればCPUではなくI/Oが原因と判断できる。

$ vmstat 1

見るべき列：

  • b：I/O待ちプロセス数（増えるとヤバい）
  • wa：I/O wait（10%以上で注意）

r が少なく b が多い場合、CPUではなくI/Oが原因。

7. 「本当にディスクが犯人か？」を確定する

結論: %iowait高・%util高・await跳ね・vmstatのb増加が同時に揃えばディスクI/Oがボトルネックとほぼ確定する。

以下が 同時に当てはまる と、ほぼ確定です。

  • %iowait が高い
  • %util が高い
  • await が跳ねている
  • vmstat の b が増える

8. 原因になりやすい代表例

結論: Docker・DB・ログ肥大・バックアップ・cronが典型的なI/O原因でこの時点で「何がI/Oを食うか」に絞り込む。

  • Docker（ログ・レイヤー・overlayfs）
  • DB（MySQL / PostgreSQL）
  • ログ肥大（access.log, error.log）
  • バックアップ（rsync, tar）
  • cronで回る重い処理

この時点で 「何がI/Oを食っているか」 を次の調査で潰す。

9. やってはいけないこと

結論: CPUだけ見て余裕と判断・証拠消える再起動・%utilだけ見て安心の3つがディスクI/O調査の典型的失敗。

NG1：CPUだけ見て「余裕」と判断

I/O待ちを見ていない典型的事故。

NG2：いきなり再起動

I/Oの証拠が消える。まず観測。

NG3：%utilだけ見て安心

await が死んでいることがある。

コピペ用：ディスクI/O調査テンプレ

# ディスク詳細（最重要）
iostat -xz 1

# 全体俯瞰
vmstat 1

# ディスク一覧（どれを見るか）
lsblk
df -h

まとめ

  • 「遅い＝CPU」ではない
  • %iowait と %util が判断軸
  • iostat と vmstat はセット
  • 観測 → 原因特定 → 対処、の順を守る

次に読む