Linuxサーバーの性能調査で iostat を見たとき、
- %util は低い
- スループットも出ていない
それなのに、
体感レスポンスは明らかに遅い
という状況に遭遇したことはないでしょうか。
本記事では、
- 「ディスクは空いている」の正体
- iostatで見落としやすい指標
- どうなれば「本当に問題ない」と判断できるか
を、実運用の切り分け目線で解説します。
まず結論：%utilが低くても「遅い」は普通に起きる
多くの人が最初に見るのは %util です。
そして、
%util が 30% しかない → ディスクは余裕
と判断します。
しかしこれは、半分正しく、半分間違いです。
なぜなら %util は、
「ディスクがどれだけ忙しかったか」
しか示していないからです。
プロセスがどれだけ待たされたかは、 %util だけでは分かりません。
iostatで本当に見るべき指標
① await（最重要）
await は、
I/O要求が発行されてから完了するまでの平均時間
です。
つまり、
- await が高い
- %util が低い
という状態は、
「ディスクは忙しくないが、応答が遅い」
ことを意味します。
SAN・仮想環境・共有ストレージでは、 この状態が非常に頻繁に発生します。
② svctmは信用しすぎない
古い情報では svctm を重視する説明がありますが、
現在のLinuxでは参考値程度に留めるべきです。
特にマルチキュー環境では、 実体と乖離することがあります。
③ r/s, w/s が少なくても安心しない
I/O回数が少なくても、
- 1回のI/Oが遅い
- 直列に処理されている
場合、アプリケーションは強く影響を受けます。
「I/Oが少ない＝問題ない」 ではありません。
「空いているのに遅い」が起きる代表的な原因
① ストレージレイテンシ（外部要因）
SAN / NAS / 仮想基盤では、
- 他ホストの影響
- バックエンドの混雑
により、Linux側からは
- %util 低い
- await 高い
という状態になります。
② swap I/O が混じっている
swap-in / swap-out が発生すると、
- I/O量は少ない
- しかし待ち時間は長い
という特徴が出ます。
vmstat で si / so が出ている場合、 ディスクが「空いて見える」だけの可能性があります。
③ I/Oキューで待たされている
ディスク自体は忙しくなくても、
- キュー深度
- スケジューラ
の影響で、 プロセスは順番待ちになります。
この場合も %util は上がりません。
正しい切り分け手順
Step1：iostatで await を確認
iostat -x 1目安として、
- await が常時 数十ms以上 → 要注意
- 瞬間的ではなく継続 → 問題あり
Step2：vmstatでブロック状態を確認
vmstat 1- b（Blocked）が増えていないか
- wa が出ていないか
ここが一致すれば、 遅さの正体はI/O待ちです。
Step3：iotopで犯人を確認
iotop -o以下が見つかれば原因特定です。
- ログ書き込み
- DB処理
- バックアップ
どうなれば「問題なし」と判断できるのか
以下が揃えば、
- await が低く安定
- b がほぼ 0
- wa が出ない
- 体感レスポンス良好
となり、本当にディスクが問題ないと言えます。
%util が低いだけでは、 判断材料として不十分です。
まとめ
- %util は「忙しさ」であり「速さ」ではない
- await が遅さの本質
- 空いているように見えるディスクほど疑う
- vmstat・iotopと必ず組み合わせる
iostatを正しく読めるようになると、
「原因不明の遅さ」
の多くは、原因不明ではなくなります。
