I/O waitが高い時にやるべき切り分け手順

URLをコピーしました！

サーバーが遅い、レスポンスが悪いと感じて調査すると、

CPU使用率は低い
メモリも余裕がある
しかし I/O wait（wa）が高い

という状態に遭遇することがあります。

本記事では、 I/O waitが高いとはどういう状態なのかを整理したうえで、 実務で使える切り分け手順を 上から順に確認すれば原因に辿り着ける形で解説します。

結論：I/O waitが高い＝「CPUが暇で待たされている」状態

I/O wait（wa）が高い状態とは、 CPUが処理したくても、I/O完了待ちで何もできない 状態を意味します。

つまり、

CPU性能の問題ではない
計算処理が重いわけでもない
ディスクや外部I/Oがボトルネック

ということになります。

まず確認：本当にI/O waitが高いのか

確認コマンド

top

CPU表示行の wa を確認します。

判断基準

wa が 10% 超で継続 → 要注意
wa が 20～30% 超 → 明確なI/Oボトルネック
CPU idle が高いのに遅い → I/O待ち濃厚

切り分け手順①：ディスクI/Oが詰まっていないか

I/O waitの原因で 最も多いのがディスクI/Oの逼迫です。

確認コマンド

iostat -x 1

見るべき項目

%util
await

判断基準

%util が 80～100% に張り付く → ディスク限界
await が高い（数十ms以上） → 応答遅延

この時点で分かること

ここで異常があれば、 原因はほぼディスクI/Oです。

切り分け手順②：どのプロセスがI/Oを発生させているか

ディスクI/Oが詰まっている場合、 誰がI/Oを出しているのかを特定します。

確認方法

iotop

判断ポイント

特定プロセスが常に上位にいる
ログ出力・バックアップ・DB処理が多い

一時的な処理なのか、常駐処理なのか をここで切り分けます。

切り分け手順③：スワップが発生していないか

メモリ不足によるスワップも、 I/O waitを急激に悪化させる原因です。

確認コマンド

free -m
vmstat 1

判断基準

si / so が継続的に増えている → スワップ発生
swap 使用量が増え続けている → メモリ不足

この場合、 I/O問題に見えて実はメモリ問題です。

切り分け手順④：NFSや外部ストレージ待ち

I/O waitは、 ローカルディスク以外のI/O待ちでも発生します。

代表例

NFSマウント
ネットワークストレージ
iSCSI / SAN

確認ポイント

特定ディレクトリ配下で遅くなる
mount している外部ストレージがある

この場合、 ネットワーク遅延やストレージ側負荷を疑います。

切り分け手順⑤：一時的か恒常的かを判断する

I/O waitが高くても、 一時的な処理であれば問題ない場合があります。

判断基準

数分で自然に下がる → 一時処理
常に高止まり → 構成・性能問題

「解決した」と判断できる状態

以下を満たせば、 I/O wait問題は解消したと判断できます。

wa が常時低い状態に戻る
await / %util が安定する
体感レスポンスが改善する
タイムアウト・遅延ログが出なくなる

実務向け切り分けチェックリスト

top で wa を確認
iostat でディスク状態確認
iotop で犯人プロセス特定
vmstat でスワップ有無確認
外部ストレージ有無確認

まとめ

I/O waitが高い場合、 CPUやアプリを疑うのは間違いです。

重要なのは、 「何を待っているのか」を切り分けることです。

本記事の手順を上から順に実施すれば、 原因を見誤らず、正しい対処に辿り着けます。