ディスクI/Oが遅いとき（iostat・iotop）
「CPUは暇なのにやけに重い」と感じたら、犯人はディスクの読み書き待ち、つまりI/Oかもしれません。top の wa やロードアベレージで疑いを持ち、iostat -x でデバイスごとの詰まり具合を、iotop でどのプロセスが読み書きしているかを特定します。ログの暴走やバックアップ処理など、よくある原因の型も併せて押さえます。
「top を見てもCPUは全然使われていない。なのに操作すると固まる」――この食い違いに出会ったら、疑うべきはCPUではなくディスクの読み書き、つまりI/Oだ。
CPUが忙しいときの重さと、I/O待ちの重さは体感がよく似ている。だが原因も対処もまるで違う。CPUを増強しても、ボトルネックがディスクなら何も変わらない。ここを見誤ると、的外れな対処に時間を溶かしてしまう。
🕵 まず疑うサイン——top の wa
最初の手がかりは、すでに使い慣れた top の中にある。画面上部の %Cpu(s) 行にある wa（I/O待ち）の値だ。
us や sy が低いのに wa が高い、あるいはロードアベレージだけが妙に高いのにCPU使用率は低い――こういう組み合わせを見たら、I/O待ちを強く疑う。
疑いを持ったら、次はディスクそのものの詰まり具合を数値で確かめる段階に進む。
📊 iostat -x でデバイスの詰まりを見る
ディスクI/Oを詳しく見る定番が iostat だ。sysstat パッケージに含まれる。
iostat -x 1 のように実行すると、1秒間隔でデバイスごとの詳細な統計が流れ続ける。数ある列の中でも、まず見るべきは %util と await の2つだ。
%util は、そのデバイスが処理でどれくらいの時間ふさがっていたかを表す割合だ。100%に張り付いていれば、そのディスクは休みなく処理し続けている、つまり限界に近い状態だと分かる。
await は、1回のI/O要求が発行されてから完了するまでにかかった平均時間（ミリ秒）だ。この値が普段より大きく伸びていれば、要求がなかなか捌けず待たされている証拠になる。
ほかにも r/s（1秒あたりの読み取り回数）と w/s（1秒あたりの書き込み回数）、rkB/s・wkB/s（1秒あたりの転送量）といった列がある。await や %util が「詰まっているかどうか」を教えてくれるのに対し、これらは「どれだけの量をこなしているか」を表す。回数は少ないのに await が長いなら、1回あたりの処理が重い大きなI/Oが起きている可能性が高い。
🔎 iotop でどのプロセスが読み書きしているか
iostat でディスク全体の詰まりが分かっても、それだけでは「誰が」原因かまでは分からない。次に使うのが iotop だ。
iotop は top によく似た画面で、プロセスごとの読み書き速度（DISK READ / DISK WRITE）をリアルタイムに表示する。上位に居座り続けるプロセスが、I/O負荷の犯人である可能性が高い。
🧩 原因の型を知っておく
I/Oが詰まる原因にはいくつかの定番パターンがある。型を知っておくと、iotop で見つけたプロセスの意味を素早く理解できる。
よくあるのが、肥大化したログファイルへの書き込みが止まらない「ログ暴走」だ。エラーが大量発生し続けるアプリが、その分だけログを書き続けてディスクを占有する。
バックアップ処理も定番の原因だ。深夜のバックアップジョブが大量のファイルを読み書きし、同時間帯の他の処理を巻き込んで遅くする。スケジュールが重なっていないかを確認する価値がある。
メモリ不足によるスワップの多発も、実はI/O問題として観測される。スワップの読み書きはディスクI/Oそのものなので、iostat 上は普通のI/O負荷として見える。この場合は free -h や vmstat も併せて確認し、真因がメモリ側にないかを見極める。
そして単純に、遅いディスクを使っている場合もある。とくに仮想化環境やクラウドの共有ストレージでは、他のテナントの負荷につられて自分のディスク性能が一時的に落ちることもあり、自分のサーバ内だけを見ていても分からないケースがある点は覚えておきたい。
💽 SSDとHDDの特性差
HDDは連続した大きなデータの読み書きは得意だが、あちこちに散らばった小さなファイルへのランダムアクセスは苦手だ。物理的にヘッドを動かす必要があるため、待ち時間（await）が伸びやすい。
SSDはランダムアクセスに強く、全体的に高速だが、無限の性能があるわけではない。書き込みが集中すれば、SSDでも%utilが張り付き、awaitが伸びることは起こりうる。
ディスクの特性を知っておくと、「このワークロードなら遅くて当然」なのか「普段より明らかにおかしい」のかを判断しやすくなる。iostat と iotop をセットで使い、詰まっている場所と原因プロセスの両方を押さえるのが、I/O障害の切り分けの基本形だ。