【完全ガイド】iostat の見方・使い方｜ディスクI/Oのボトルネックを特定する方法を徹底解説

Linux サーバー運用でパフォーマンス問題が発生した時、真っ先に疑うべきはディスクI/O。CPU使用率もメモリも余裕があるのに、なぜかシステムが遅い…そんな時に頼りになるのが iostat コマンド:

$ iostat -x 1
Linux 5.15.0-generic (server)  06/20/2026  _x86_64_  (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.24    0.00    1.12   35.56    0.00   60.08

Device    r/s    w/s   rkB/s   wkB/s  r_await  w_await  aqu-sz  %util
sda    150.00  30.00  9600.00  480.00    45.20    12.10    3.50   98.50

上の例では %iowait 35%、%util 98.5%、r_await 45ms で明らかにディスクI/Oがボトルネック。

しかし、いざ使おうとすると:

• 出力の各列が何を意味するか分からない
• %util が100% でも問題ない場合があるって本当？
• SSD/NVMe での %util の見方は？
• await と svctm の違いは？
• aqu-sz はいくつなら危険？
• どうやってボトルネックを特定する？
• どのプロセスが原因か分からない
• vmstat / iotop / sar とどう使い分ける？

など、iostat は情報が豊富すぎて正しい読み方を知らないと逆に判断を誤る難しさがあります。

本記事では、iostat の完全な使い方と読み方を、リファレンスとして実用的に整理します。インストール、基本コマンド、出力の完全解読（CPU/Device 全メトリクス）、主要オプション、ボトルネック特定フレームワーク、SSD/NVMe での注意点、関連ツール（iotop/vmstat/sar）との連携、実践シナリオ、トラブルシューティング、FAQまで完全網羅。この1本でディスクI/O パフォーマンス問題を確実に特定・解決できるようになります。

結論：ボトルネック特定の3ステップ

時間がない方向けに、最短の対処手順を示します。

ステップ1：CPU の iowait を確認

iostat 1
# %iowait > 20% なら I/O がボトルネックの可能性

ステップ2：詳細な device 統計

iostat -xm 1
# 注目するメトリクス:
# - %util（デバイスの忙しさ）
# - r_await / w_await（レイテンシ、ms）
# - aqu-sz（キュー長）

ステップ3：原因プロセス特定

sudo iotop -o
# I/O を発生させているプロセスを特定

ボトルネックの判定基準

詳細は以下で解説します。

iostat の導入

インストール

iostat は sysstat パッケージに含まれます:

# Ubuntu / Debian
sudo apt install sysstat

# RHEL / CentOS / Rocky / AlmaLinux
sudo dnf install sysstat
# または
sudo yum install sysstat

# Arch Linux
sudo pacman -S sysstat

# macOS（Homebrew）
brew install sysstat
# ※ macOS は挙動が異なる

バージョン確認

iostat -V
# sysstat version 12.5.4

sysstat に含まれるツール

• iostat: I/O とCPU統計
• mpstat: マルチプロセッサ統計
• pidstat: プロセス別統計
• sar: 過去の統計データ収集・表示
• sadf: sar データ変換

基本的な使い方

引数なしで実行

iostat

出力例:

Linux 5.15.0-generic (server)  06/20/2026  _x86_64_  (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.23    0.00    2.15    1.82    0.00   90.80

Device            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             45.23       512.45       234.12   51234567   23456789
sdb             12.34        89.23        45.67    8923456    4567890

⚠️ 初回の出力は起動時からの平均。リアルタイム値ではないので注意。

定期的なサンプリング

# 2秒ごと、5回
iostat 2 5

# 1秒ごと、無限
iostat -x 1
# Ctrl+C で終了

2回目以降が「直前のサンプリング期間」の値。これがリアルタイム。

特定デバイスのみ

iostat -d sda 2
# sda だけを2秒ごと表示

# 複数
iostat -x sda nvme0n1 1

CPU 統計を省略

iostat -d
# CPUセクションを省略、Device のみ

単位を MB に

iostat -m
# kB → MB に変更

大容量サーバーでは MB が見やすい。

CPU セクションの読み方

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.23    0.00    2.15   35.56    0.00   57.06

各列の意味:

%iowait の読み方（最重要）

%iowait: CPU が「暇だけど、I/O が終わるのを待って何もしていない」時間の割合。

• 0-5%: 正常
• 5-20%: 中程度、要監視
• 20% 以上: ディスクI/Oがボトルネックの可能性大
• 50% 以上: 深刻

%iowait の落とし穴

⚠️ %iowait は当てにならない場合がある:

• CPU が忙しいと %iowait は下がる（他プロセスが CPU を使うため）
• %iowait が低くても I/O 遅延はある

例：

%user 80%, %iowait 5% → 見た目は正常でも、I/O遅延はあり得る

%iowait だけで判断せず、必ず Device セクションも確認。

%steal の意味

仮想サーバー（AWS EC2 等）で高いと、隣の VM が CPU を占有している可能性:

• 0%: 通常
• 10% 以上: 隣のVMの影響大、インスタンスタイプ変更検討

Device セクション（基本）

Device        tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda         45.23       512.45       234.12   51234567   23456789

tps（IOPS）の目安

デバイスの理論値を大きく超えるIOPSが発生していれば、キャッシュ効いてる or メトリクス誤りの可能性。

Device セクション（拡張 -x）

-x オプションで大幅に詳細な情報が得られます:

iostat -x 1

出力例:

Device    r/s    w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %rrqm  %wrqm r_await  w_await aqu-sz  rareq-sz  wareq-sz  svctm  %util
sda    150.00  30.00 9600.00  480.00   0.00    5.00   0.00  14.29   45.20    12.10   3.50    64.00     16.00   0.80  98.50

各列の完全解説

基本 I/O

r/s + w/s = tps（基本 iostat の tps）

マージ（結合）

マージ: 隣接ブロックへのリクエストをカーネルが結合。多いほどシーケンシャルI/O。

レイテンシ（重要）

await = キュー待ち時間 + サービス時間。

これが低ければ低いほど良い:

await > 100ms は明確な遅延問題。

キュー

aqu-sz > 1: 継続的に待ちが発生している可能性。特に HDD で問題。

リクエストサイズ

• 小さい（4KB程度）: ランダムI/O 多い
• 大きい（数百KB）: シーケンシャルI/O 多い

使用率

要注意メトリクス（後述）。

svctm（非推奨）

⚠️ sysstat 12.0+ で非推奨、削除されつつある。信用しないこと。

%util の正しい読み方（重要）

HDD（磁気ディスク）の場合

HDD は単一リクエストしか同時処理できない:

• %util 100% = 常に何かしている = 飽和
• %util > 80% は要注意、100% は明確なボトルネック

SSD / NVMe の場合

SSD/NVMe は複数リクエストを並列処理可能:

• %util 100% でも「1リクエスト以上を処理している時間」の意味に過ぎない
• 実際の容量にはまだ余裕があることが多い

⚠️ SSD/NVMe で %util = 100% を見ても、必ずしも飽和ではない。

SSD/NVMe では await を重視

NVMe SSD:
- %util: 100%（見た目パニック）
- await: 0.2ms（実は超余裕）
- → 問題なし

NVMe SSD:
- %util: 50%
- await: 20ms（10倍のレイテンシ）
- → 深刻な問題

RAID / LVM でも同様

RAID や LVM は論理デバイスとしては複数リクエスト並列。%util の解釈に注意。

主要オプション一覧

便利な組み合わせ

# 実務標準：拡張統計、MB、タイムスタンプ、活動あるデバイスのみ、1秒間隔
iostat -xmtz 1

# 初回の起動時累積を省略（-y）
iostat -xmy 1

# 特定デバイス、パーティション含む
iostat -xp sda 1

# JSON 出力（プログラム連携）
iostat -xt -o JSON 1 10

パーティション単位で見る

iostat -p sda 1

出力:

Device     tps    kB_read/s    kB_wrtn/s
sda      45.23       512.45       234.12
sda1     35.10       400.00       150.00
sda2     10.13       112.45        84.12

パーティションごとにI/O 傾向を確認。OSとデータ領域を分けている場合の分析に有効。

タイムスタンプと記録

定期記録

# 5秒ごと、720回（1時間分）をログに記録
iostat -xmt 5 720 > /tmp/iostat.log

# バックグラウンドで
nohup iostat -xmt 5 720 > /tmp/iostat.log 2>&1 &

詳細はLinuxでプロセスをバックグラウンド実行する方法の記事も参照。

定期監視（sar 経由）

sysstat には継続的にデータを記録する仕組みが含まれる:

# sysstat を有効化
sudo systemctl enable --now sysstat

# 過去のデータを見る
sar -d -p  # 直近のディスクI/O
sar -d -p -s 09:00:00 -e 10:00:00  # 時間指定

デフォルトで /var/log/sa/ に日次データを保存。

詳細はsystemctl vs service の記事、crontab 書き方 例の記事も参照。

ボトルネック特定のフレームワーク

USE メソッド

Brendan Gregg 提唱のUtilization / Saturation / Errors:

判定フロー

1. %iowait をチェック → 20%以上ならI/O疑い
        ↓
2. iostat -x で全デバイス確認
        ↓
3. どのデバイスが %util 高い / await 高い？
        ↓
4. HDDなら %util、SSDなら await 重視
        ↓
5. aqu-sz > 1 なら明確な飽和
        ↓
6. iotop で原因プロセス特定
        ↓
7. dmesg / journalctl でエラー確認

典型的なパターン

パターンA：シーケンシャル読み込みの飽和

r/s: 200, rkB/s: 100000, w/s: 5, wkB/s: 100
%util: 100, r_await: 30ms, aqu-sz: 4
rareq-sz: 500KB, %rrqm: 60%

→ 大量シーケンシャル読み込み（バックアップ、DB フルスキャン等）。マージ多い、キュー詰まり。

パターンB：ランダム書き込み集中

r/s: 10, w/s: 5000, rkB/s: 100, wkB/s: 40000
%util: 100, w_await: 15ms, aqu-sz: 10
wareq-sz: 8KB, %wrqm: 5%

→ 多数の小さいランダム書き込み（DB writes等）。マージ少ない、SSD向き。

パターンC：偶発的なスパイク

（多くの時間は静か、時々突発）

→ 特定処理（cron、バックアップ）の影響。時系列で見る。

実践シナリオ

シナリオ1：Webサーバーの遅延調査

# 1. iowait 確認
iostat 1
# %iowait 40% → I/O疑い

# 2. どのデバイス
iostat -xm 1
# sda: %util 100%, r_await 200ms → 深刻

# 3. 犯人プロセス
sudo iotop -o
# postgres: Read 500 MB/s → DB プロセス

シナリオ2：データベース性能問題

# 定常監視
iostat -xmt 5 60 > db_io.log

# 特定時刻の詳細
grep "10:15" db_io.log

# 特に注目
awk '/nvme|sd/ {if($10>10) print}' db_io.log
# w_await > 10ms のラインを抽出

詳細はLinux grep オプション一覧の記事、Linux awk 使い方の記事も参照。

シナリオ3：バックアップ影響の測定

# バックアップ前
iostat -xm 5 6 > before.log

# バックアップ実行
sudo nice -n 19 ionice -c 3 tar czf /backup/data.tar.gz /data

# バックアップ中
iostat -xm 5 6 > during.log

# 比較
diff before.log during.log

詳細はLinuxでファイル差分を確認する方法の記事も参照。

シナリオ4：Docker コンテナのI/O影響

# ホスト側で全体確認
iostat -xm 1

# コンテナ内から
docker exec -it container_name iostat -xm 1

# コンテナ別
docker stats

詳細はdocker daemon 接続エラーの記事、Docker no space left on device の記事も参照。

シナリオ5：仮想化環境の I/O

iostat -x 1
# %steal 15% → ホストで奪われてる
# %iowait 30% → I/O 待ち多い

→ ハイパーバイザ側のリソース競合を疑う。EC2 なら EBS 監視も。

シナリオ6：cron 実行時の影響

# 実行前後で iostat 記録
crontab -e

0 3 * * * (iostat -xm 60 5; /opt/scripts/backup.sh; iostat -xm 60 5) > /var/log/backup_io.log 2>&1

詳細はcrontab 書き方 例の記事も参照。

シナリオ7：SSD の寿命診断

# 書き込み量が多すぎるか
iostat -m

# SMART 情報と組み合わせ
sudo smartctl -a /dev/sda | grep -i wear

シナリオ8：Rails / Solid Queue のI/O

# Solid Queue worker のI/O 影響
sudo iotop -oP | grep -i "queue\|ruby"

# 全体のディスク統計
iostat -xm 1

詳細はSolid Queue 使い方の記事、Solid Cache 使い方の記事も参照。

関連ツールとの連携

iotop：プロセス別 I/O

sudo iotop
# インタラクティブに I/O 使用量を表示

# アクティブのみ、バッチ
sudo iotop -o -b -n 5

# プロセス集約
sudo iotop -oP

iostat で「どのディスクか」、iotop で「どのプロセスか」。

vmstat：メモリと I/O

vmstat 1

 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
  1  3      0 123456   1234 456789    0    0   500  1500  200  400  5  2 60 30  0

• b: ブロックされたプロセス数（I/O 待ち）
• bi: 秒間ブロック入力（読み）
• bo: 秒間ブロック出力（書き）
• wa: CPU の I/O 待ち時間割合（iowait と同じ）

b > 0 が継続すれば I/O ボトルネック。

sar：時系列データ

# ディスクI/O 時系列
sar -d -p 1 5

# 過去のデータ
sar -d -p -s 09:00:00 -e 10:00:00

# CPU 時系列
sar -u 1 5

# メモリ
sar -r 1 5

過去のトラブル分析に必須。

dstat：統合ツール

sudo apt install dstat  # インストール

dstat -cdnl 1
# CPU / Disk / Network / Load の統合表示

新しいマシンでは pcp-dstat が推奨。

pidstat：プロセス別統計

# I/O 統計
pidstat -d 1

# 特定プロセス
pidstat -d -p 12345 1

blktrace：ブロックレベル詳細

sudo blktrace -d /dev/sda -o - | blkparse -i -
# I/O 1つ1つを追跡（本格的な調査用）

ioping：レイテンシ測定

sudo ioping /var
# --- /var (ext4 /dev/sda1) ioping statistics ---
# 4KiB read: 1234 iops, 4.83MB/s (avg)

トラブルシューティング

iostat: command not found

sudo apt install sysstat        # Ubuntu/Debian
sudo dnf install sysstat        # RHEL系

全て0 が表示される

# sysstat が無効の可能性
sudo systemctl status sysstat

# 有効化
sudo systemctl enable --now sysstat

出力の意味が分からない列がある

man iostat
# 詳細な説明

または sysstat のバージョンで表示項目が違うこともある:

iostat -V
# sysstat version 12.5.4

%util 100% だが遅くない

→ SSD/NVMe の可能性。await を重視。

await が異常に高い

# ハードウェア障害を疑う
sudo dmesg | grep -i error
sudo smartctl -a /dev/sda
sudo journalctl -k | grep -i "I/O error"

詳細はsystemctl vs service の記事（journalctl）も参照。

aqu-sz が異常に大きい

キューが詰まっている。原因:

• ハードウェア障害
• 過負荷
• IO スケジューラ問題

# スケジューラ確認
cat /sys/block/sda/queue/scheduler
# [mq-deadline] kyber bfq none

Docker container 内で iostat が動かない

docker exec -it container iostat
# エラー？

→ container 内に sysstat インストール:

docker exec -it container apt install -y sysstat

仮想マシンで意味不明な値

• %steal が高い: ハイパーバイザに奪われてる
• await が異常: 共有ストレージの競合
• CPU 情報が実物と違う: hypervisor の情報

物理環境と別扱いで解釈を。

よくある質問（FAQ）

Q1. iostat の初回出力は何？

システム起動時からの累積平均。リアルタイム値ではない。実際の監視は2回目以降を使う。

または -y オプションで初回を省略:

iostat -xy 1

Q2. %util 100% は常に問題？

• HDD: ほぼ確実に問題
• SSD/NVMe: 参考程度、await を見る

Q3. どのメトリクスを常時監視すべき？

優先度順:

1. await（レイテンシ） – 最重要
2. aqu-sz（キュー） – 飽和指標
3. %util – HDD なら有効
4. r/s + w/s（IOPS） – 負荷傾向
5. %iowait – CPU から見た指標

Q4. 具体的にどのプロセスがI/O 発生させているか

iotop を使う:

sudo iotop -oP

または pidstat -d。

Q5. 過去のI/O 状態を見たい

sar を使う:

sar -d -p -f /var/log/sa/sa20   # 過去のファイル

Q6. Grafana / Prometheus と連携したい

Prometheus node_exporter でディスク I/O メトリクス収集:

node_disk_io_time_seconds_total
node_disk_reads_completed_total
node_disk_writes_completed_total

Q7. AWS EBS の監視

CloudWatch で以下も監視:

• VolumeReadBytes / VolumeWriteBytes
• VolumeReadOps / VolumeWriteOps
• VolumeQueueLength
• BurstBalance（gp2）

Q8. NVMe の飽和を判定する方法

1. await が普段より 5倍以上 → 危険
2. aqu-sz が継続的に > 32 → 飽和
3. IOPS が理論値の 80% 超 → 飽和近い

Q9. 単位が k/M/G 混在で読みにくい

iostat -xh 1   # human readable
# または --pretty

Q10. Docker / Kubernetes での I/O 監視

• Docker: docker stats + iostat（ホスト）
• Kubernetes: kubectl top pod + node の iostat
• cAdvisor: コンテナ別 I/O メトリクス

Q11. RAID の各ディスクを見たい

iostat -x md0 sda sdb sdc 1
# md0（RAID デバイス）と物理ディスク両方

Q12. iostat のログを CSV に変換

iostat -xt 1 | awk '/^Device/ {header=1; next} 
                     /^[a-z]/ && header {print}' > iostat.csv

または -o JSON を利用。

参考リンク・関連資料

公式

• iostat(1) – Linux manual page – iostat 公式
• sysstat 公式 – sysstat プロジェクト
• Brendan Gregg’s Performance – パフォーマンス解析の権威

関連ツール

• iotop – プロセス別 I/O
• ioping – レイテンシ測定
• blktrace – ブロックレベル追跡

関連記事（本サイト）

• systemctl vs service – サービス管理（sysstat デーモン）
• Linuxでプロセスをバックグラウンド実行する方法 – nohup で長時間監視
• Linux kill vs pkill vs killall – プロセス終了
• docker daemon 接続エラー – Docker 管理
• Docker no space left on device – ディスク容量
• Linux find オプション一覧 – ファイル検索
• Linux grep オプション一覧 – ログ検索
• Linux awk 使い方 – データ加工
• Linuxでファイル差分を確認する方法 – 監視ログ比較
• crontab 書き方 例 – 定期実行監視
• scp vs rsync – ファイル転送
• SSH host key verification failed – リモート監視
• Solid Queue 使い方 – Rails ジョブ管理
• Solid Cache 使い方 – Rails キャッシュ

まとめ

iostat によるディスクI/O 監視、要点を再整理します。

押さえるべき5つのメトリクス

主要コマンド

# 基本
iostat -xm 1                    # 拡張・MB・1秒間隔

# 記録
iostat -xmt 5 720 > /tmp/io.log # 1時間分

# 活動あるデバイスのみ
iostat -xmtz 1

# 特定デバイス
iostat -x sda nvme0n1 1

# JSON 出力
iostat -xt -o JSON 1 10

判定フロー

%iowait > 20% → I/O疑い
       ↓
iostat -x → デバイス特定
       ↓
HDD: %util重視 / SSD: await重視
       ↓
aqu-sz > 1 → 飽和確定
       ↓
iotop で原因プロセス
       ↓
dmesg でエラー確認

SSD/NVMe での注意

• %util 100% でも問題ないケースあり
• await を重視（0.5ms 以下が理想）
• aqu-sz と IOPS の伸びを確認

ベストプラクティス

• sysstat を常時有効化（過去データ取得）
• iotop と併用（プロセス特定）
• baseline を知る（正常時の値を記録）
• 時系列で見る（スパイクは瞬間だけ）
• 仮想化は %steal も見る
• RAID/LVM は %util を過信しない

関連ツール使い分け

これらの知識は、サーバー性能問題の切り分け・データベース最適化・仮想化環境の運用・容量計画など、あらゆる場面で活用できます。本記事をブックマークしておけば、ディスクI/O トラブルを確実に特定・解決できるようになります。

本記事は2026年6月時点の情報をもとに、sysstat 12.5+、Linux Kernel 6.x、Ubuntu 22.04/24.04、RHEL 9 での動作確認・公式ドキュメントに基づき作成しています。sysstat のバージョンやディストリビューションによって出力形式が異なる場合があるため、最新の情報は man ページ（man iostat、man sar、man vmstat）もあわせてご確認ください。