ディスクI/Oが逼迫する原因と対処（ログ・バックアップ・DB）

サーバーのレスポンスが悪化し、調査すると

• I/O wait が高い
• CPU使用率は低い
• メモリも余裕がある

このような状態で多くの場合、 ディスクI/Oの逼迫が発生しています。

本記事では、 ディスクI/Oが逼迫する典型的な原因を 「ログ」「バックアップ」「DB」に分けて解説し、 運用現場でそのまま使える対処方法を整理します。

結論：ディスクI/O逼迫は「処理量 × タイミング × 構成」で決まる

ディスクI/Oは、

• 大量に書き込む処理
• 一気に読み込む処理
• 同時実行される処理

が重なることで簡単に限界に達します。

重要なのは、 「何が」「いつ」「どれくらい」I/Oを出しているか を把握することです。

まず確認：本当にディスクI/Oが逼迫しているか

確認コマンド

iostat -x 1

見るべき指標

• %util
• await

判断基準

• %util が 80～100% に張り付く → 明確な逼迫
• await が高い → I/O応答遅延

原因①：ログ出力が多すぎる

よくあるケース

• アプリケーションのデバッグログ
• アクセスログの大量出力
• エラーループによるログ増加

確認方法

iotop

ログ関連プロセスが常に上位に表示される場合、 ログ出力が原因の可能性が高いです。

対処方法

• ログレベルを下げる（INFO → WARN）
• 不要なログ出力を停止
• ログを別ディスクに分離

解決した判断基準

• ログ出力量が減少
• iostat の %util が低下

原因②：ログローテートが集中実行されている

問題点

logrotate は 圧縮・リネーム・削除を一気に行うため、 短時間で大量I/Oを発生させます。

確認方法

crontab -l
ls /etc/cron.*

対処方法

• 実行時間をピーク外に変更
• 圧縮を遅延実行（delaycompress）
• 同時ローテート数を減らす

解決した判断基準

• 特定時刻のみのI/Oスパイクが消える

原因③：バックアップ処理による大量I/O

よくある例

• rsync によるフルバックアップ
• tar + gzip の一括圧縮
• スナップショット取得

確認方法

iotop
ps aux | grep backup

対処方法

• 差分バックアップに変更
• nice / ionice で優先度を下げる
• バックアップ時間を分散

解決した判断基準

• バックアップ中でもサービス影響が出ない

原因④：データベース（DB）のI/O負荷

典型的な原因

• フルスキャンが頻発
• インデックス不足
• チェックポイント・フラッシュ集中

確認方法

iotop
top

DBプロセス（mysqld など）がI/O上位を占めます。

対処方法

• インデックス設計の見直し
• バッファサイズ調整
• 不要なクエリの停止

解決した判断基準

• DB処理時の await が低下
• レスポンス改善

原因⑤：ディスク性能そのものが不足

兆候

• 常時 %util が高い
• 対処しても改善しない

対処方法

• SSD / NVMe への変更
• ディスク分割（ログ・DB分離）
• RAID / ストレージ構成見直し

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

• iostat の %util が安定して低い
• await が数msレベル
• I/O wait が常時低下
• 業務時間帯の遅延が消える

実務向けチェックリスト

1. iostat で逼迫確認
2. iotop で犯人特定
3. ログ・バックアップ・DBを疑う
4. 時間帯と処理内容を確認
5. 構成見直しで根本対応

まとめ

ディスクI/O逼迫は、 原因を特定できれば対処は難しくありません。

重要なのは、 感覚ではなく数値で判断することです。

本記事の手順で確認すれば、 「なぜ遅いのか」「どう直すか」が明確になります。