I/Oボトルネックの特定方法（top・iostat・sar・pidstatの見方）

サーバーが遅いとき、CPU は空いているのに処理が進まない場合は、ディスクの読み書き（I/O）が詰まっていることがあります。この記事では、Linux の標準的なコマンドで「I/O が原因か」「どのディスクか」「どのプロセスか」を順に絞り込みます。コマンドの動作と出力の列は、2026年11月時点で Debian 13 の sysstat 12.7.5 と、iostat の公式マニュアルで確認しています。

準備：sysstat を入れる

iostat・sar・pidstat は sysstat というパッケージに入っています。

# Ubuntu／Debian
sudo apt install sysstat

# RHEL 系（AlmaLinux・Rocky Linux など）
sudo dnf install sysstat

ステップ1：top と vmstat で I/O 待ちがあるかを見る

top の3行目（%Cpu(s)）の wa は、CPU が I/O の完了を待って何もしていない時間の割合です。

%Cpu(s):  2.1 us,  1.0 sy,  0.0 ni, 60.3 id, 36.4 wa,  0.0 hi,  0.2 si,  0.0 st

この例のように wa が高く、us・sy（CPU の処理）が低い場合は、I/O 待ちが疑われます。top の画面でプロセスの S（状態）の列が D のプロセスは、I/O などの完了を待って止まっているプロセスです。なお、top は CPU とメモリの使用量をプロセスごとに表示しますが、プロセスごとの I/O 量は表示しません（ステップ4のコマンドを使います）。

一定の間隔で数字を並べて見るには vmstat が便利です。

vmstat 1 5    # 1秒ごとに5回

wa は CPU が暇なときにしか増えないので、CPU が忙しいサーバーでは I/O が詰まっていても低く出ることがあります。wa だけで判断せず、次の iostat でディスクの側を確かめます。

ステップ2：iostat -x でどのディスクが詰まっているかを見る

iostat -dxyz 1 5

-y を付けないと、最初の1回分は起動してからの平均になり、今の状況とは違う数字が出ます。

見る列は次のとおりです。

読み方

• r_await・w_await が普段より大きく伸びているときは、ディスクが要求をさばききれず、待ちが発生しています。どのくらいが正常かはディスクの種類で大きく違うので、普段の値と比べます。
• aqu-sz が大きいときは、要求がたまっています。
• %util は HDD など1件ずつ処理するディスクでは、値が上限近くに張り付いていれば飽和の目安になります。ただし、iostat のマニュアルにあるとおり、RAID や最近の SSD のように複数の要求を同時に処理するデバイスでは、%util は性能の限界を表しません。SSD や NVMe では %util が上限近くでも余裕がある場合があるので、await と aqu-sz で判断します。

古い資料には svctm・avgrq-sz・avgqu-sz などの列が出てきます。現在の sysstat では svctm は表示されず、avgrq-sz は areq-sz（単位は KB）、avgqu-sz は aqu-sz に置き換わっています。

デバイス名（sda・nvme0n1・dm-0 など）がどのファイルシステムに当たるかは、lsblk で確かめられます。

lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS

ステップ3：sar で過去の状況を見る

iostat は今の状況しか見られません。「昨日の夜だけ遅かった」のような場合は、sar が定期的に記録したデータを見ます。

記録を有効にする

# Ubuntu／Debian：記録が無効になっていれば有効にする
grep ENABLED /etc/default/sysstat
sudo sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat
sudo systemctl restart sysstat

# RHEL 系
sudo systemctl enable --now sysstat

Debian 13 では、インストールした直後の ENABLED は "false" でした。有効にすると、systemd のタイマー（sysstat-collect.timer）で既定では10分ごとに記録され、Debian／Ubuntu では /var/log/sysstat/、RHEL 系では /var/log/sa/ に日付ごとのファイル（saDD、DD は日）ができます。記録は有効にしたあとの分からしか残らないので、問題が起きる前から有効にしておきます。

記録を見る

# 今日のディスクの記録（-p でデバイス名を sda などで表示）
sar -d -p

# 今日の CPU の記録（%iowait の列を見る）
sar -u

# 10日の記録の、22時から23時まで
sar -d -p -f /var/log/sysstat/sa10 -s 22:00:00 -e 23:00:00

sar -d の列は、tps（1秒あたりの要求数）、rkB/s・wkB/s、areq-sz、aqu-sz、await、%util です。iostat -x と同じ考え方で読み、await と aqu-sz が伸びている時間帯を探します。その時間帯に動いていた処理（バックアップ、cron のバッチ、ログの圧縮など）を突き合わせると、原因が見つかることがよくあります。

sar -d 1 5 のように間隔と回数を付けると、記録ではなく今の状況を測ります。

ステップ4：pidstat と iotop で I/O の多いプロセスを探す

pidstat -d

pidstat -d 1 5

ほかのユーザーのプロセスまで見るには sudo を付けて実行します。

iotop

iotop は、top のようにプロセスを I/O の量の順に並べて表示します（sudo apt install iotop などで入れます）。

sudo iotop -o    # 実際に I/O をしているプロセスだけを表示

カーネルの設定によっては、起動時に CONFIG_TASK_DELAY_ACCT や kernel.task_delayacct についての警告が出て、IO>（I/O 待ちの割合）の列が表示されません。その場合でも、読み書きの量の列は使えます。

原因が見つかったあとの対処の例

注意

• 1回の測定は一瞬の状況にすぎません。数分から数十分測る、または sar の記録で時間の流れを見ます。
• VPS やクラウドでは、同じ物理ディスクを使うほかの利用者の影響や、プランごとの IOPS の上限で遅くなることもあります。await が伸びているのに自分のサーバーの I/O 量が少ない場合は、提供元の情報も確かめます。

sar のほかの使い方（CPU・メモリ・ネットワーク）は Linuxのsarコマンドでシステムの状態を記録する方法 を参照してください。

まとめ

1. top・vmstat の wa と b で、I/O 待ちが起きているかを見ます。
2. iostat -dxyz 1 5 で、r_await・w_await・aqu-sz が伸びているディスクを探します。SSD や NVMe では %util だけで判断しません。
3. 過去の時間帯は sar -d -p で見ます。記録はあらかじめ有効にしておきます。
4. pidstat -d や iotop -o で、読み書きの多いプロセスを特定して対処します。