【Ubuntu】ディスクI/Oが遅いときの調べ方:iostat / vmstat でボトルネックを特定する(原因切り分けの型)

ディスクI/Oトラブルシューティング - iostat/vmstat

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

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

結論(最短ルート)

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

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

目次

  1. ディスクI/Oが遅いとは何か
  2. iostat を使う準備
  3. iostat -xz で全体を見る
  4. 重要指標の読み方(%iowait / %util / await)
  5. よくあるパターンと判断
  6. vmstat で全体像を掴む
  7. 「本当にディスクが犯人か?」を確定する
  8. 原因になりやすい代表例
  9. やってはいけないこと

前提(対象環境)

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

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

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

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

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

2. iostat を使う準備(入っていない場合)

$ sudo apt update
$ sudo apt install -y sysstat

3. まずは全体を見る(iostat -xz)

$ iostat -xz 1

オプションの意味:

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

4. 重要指標の読み方(ここが核心)

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. よくあるパターンと判断

パターン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:I/O wait(10%以上で注意)

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

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

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

  • %iowait が高い
  • %util が高い
  • await が跳ねている
  • vmstatb が増える

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

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

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

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

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

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

NG2:いきなり再起動

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

NG3:%utilだけ見て安心

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

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

# ディスク詳細(最重要)
iostat -xz 1

# 全体俯瞰
vmstat 1

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

まとめ

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

検証環境

本記事のコマンドは Ubuntu 24.04 LTS / bash 5.2 で動作確認済みです。

次に読む