LinuxのディスクI/Oが高いときの確認方法｜サーバーが遅い原因を調べる手順
[本文]
Linuxサーバーを使っていると、「CPU使用率はそれほど高くないのに動作が遅い」「ディスク容量は十分なのにSSHやWebサイトの反応が悪い」といったことがあります。
このような場合は、ディスクI/Oが原因になっていないか確認してみましょう。
ディスクI/Oとは、ストレージに対してデータを読み書きする処理のことです。
大量のログ書き込み、データベース処理、バックアップ、Dockerの処理などが集中すると、CPUやディスク容量に問題がなくてもサーバー全体の動作が遅くなることがあります。
ディスク容量とディスクI/Oは別の問題
まず理解しておきたいのが、「ディスク容量が足りないこと」と「ディスクI/Oが高いこと」は別の問題だという点です。
例えば、
ディスク容量
500GB中100GB使用
なら、容量には十分余裕があります。
しかし、そのディスクに対して大量の読み書きが同時に発生していると、処理が遅くなることがあります。
つまり、
容量に余裕がある
↓
それでもサーバーが遅い
↓
ディスクI/Oを確認する
という切り分けが必要です。
まずtopでI/O Waitを確認する
最初にtopを実行します。
top
画面上部にCPUの使用状況が表示されます。
環境によって表示形式は異なりますが、次のような項目を確認できます。
%Cpu(s): 10.0 us, 5.0 sy, 0.0 ni, 20.0 id, 65.0 wa
ここで注目したいのがwaです。
waはI/O Wait、つまりCPUがディスクなどのI/O処理を待っている時間の割合を示します。
waが高い状態が継続している場合、ディスクI/Oがサーバーの処理を妨げている可能性があります。
ただし、waが一度高くなっただけでディスクが故障していると判断することはできません。
一時的なバックアップやログ処理などでも上昇するため、継続しているか確認してください。
iostatでディスクI/Oを詳しく確認する
ディスクI/Oを詳しく確認するときに便利なのがiostatです。
iostat
環境によってはコマンドがインストールされていない場合があります。
Linuxでは、sysstatパッケージに含まれていることが一般的です。
インストール後は、次のように実行できます。
iostat -xz 1
1秒ごとにディスクの状態を確認できます。
特に確認したい項目として、
%utilawaitr/sw/srkB/swkB/s
などがあります。
これらを見ることで、どの程度の読み書きが発生しているのか、I/O処理にどの程度時間がかかっているのかを確認できます。
%utilが高い場合は何を意味する？
iostatでは、%utilという項目があります。
これはストレージデバイスがI/O処理に使用されている割合を見るための指標です。
高い状態が継続している場合は、そのデバイスにI/Oが集中している可能性があります。
ただし、ストレージの種類や性能、RAID構成、仮想環境などによって意味は変わります。
そのため、
%utilが高い
↓
必ずディスク故障
と判断するのではなく、
%util
+
await
+
I/O量
+
プロセス
+
ログ
を合わせて確認することが重要です。
awaitが高い場合も確認する
iostatではawaitも重要です。
これはI/O要求が完了するまでにかかった時間を見るための指標です。
awaitが高い状態が続いている場合、I/O処理が混雑している可能性があります。
例えば、大量のデータベース処理やバックアップ処理が同時に発生していると、I/O待ち時間が増えることがあります。
ただし、どの数値を「高い」と判断するかは、ストレージの種類やサーバーの用途によって異なります。
普段の状態を記録しておき、通常時と比較することも有効です。
どのプロセスがディスクを使っているか確認する
I/Oが高いことが分かったら、次に「誰がディスクを使っているのか」を確認します。
環境によってはiotopを利用できます。
sudo iotop
リアルタイムでディスクI/Oを発生させているプロセスを確認できます。
例えば、
- mysqld
- postgres
- nginx
- rsync
- backup処理
- Docker関連プロセス
などが大量のI/Oを発生させていることがあります。
iotopが利用できない環境では、pidstatなど別のツールを利用する方法もあります。
pidstat -d 1
環境によって利用できるコマンドは異なるため、インストール状況を確認してください。
ログが大量に書き込まれていないか確認する
ディスクI/Oが急に高くなった場合、ログの大量出力も原因の一つです。
例えば、アプリケーションで同じエラーが繰り返されていると、
エラー発生
↓
ログへ書き込み
↓
再びエラー
↓
ログへ書き込み
↓
大量のログが生成される
という状態になることがあります。
ディスク容量が減っていなくても、短時間に大量のログを書き込めばI/O負荷が高くなる可能性があります。
そのため、サーバーが突然重くなった場合はログも確認してください。
journalctlのログを確認する
systemdを利用しているLinuxでは、journalctlでシステムやサービスのログを確認できます。
例えば、
journalctl --since "30 minutes ago"
のように、直近のログを確認できます。
特定のサービスだけ確認する場合は、
journalctl -u nginx --since "30 minutes ago"
のように指定します。
同じエラーが大量に繰り返されていないか、サーバーが重くなった時間帯に何か異常が発生していないかを確認しましょう。
DockerでもディスクI/Oが増えることがある
Docker環境では、コンテナ内のアプリケーションが大量のファイルを読み書きすることでI/O負荷が高くなる場合があります。
例えば、
- 大量のログ
- データベース
- キャッシュ
- 一時ファイル
- 大量のアップロード
- ビルド処理
などです。
Dockerコンテナの状態を確認するには、
docker stats
が使えます。
ただし、docker statsは主にCPUやメモリなどの状態を確認するコマンドです。
ディスクI/Oの原因を詳しく調べる場合は、ホスト側のiotopやpidstatなども合わせて確認してください。
データベースがI/Oを大量に使うケース
MySQLやPostgreSQLなどのデータベースは、状況によって大量のディスクI/Oを発生させることがあります。
例えば、
- 大量のSELECT
- 大量のINSERT
- UPDATE処理
- インデックス処理
- バックアップ
- テーブルのメンテナンス
などです。
特にアクセスが増えたタイミングでI/Oが急上昇する場合は、データベースの処理内容も確認する必要があります。
「サーバーのディスクが遅い」と決めつける前に、データベース側の負荷を確認することが重要です。
バックアップ処理も確認する
サーバーが毎日決まった時間だけ重くなる場合、バックアップが原因になっていることがあります。
例えば、
深夜2:00
↓
バックアップ開始
↓
大量のファイルを読み込む
↓
圧縮・保存
↓
ディスクI/O上昇
↓
サーバーが一時的に遅くなる
というケースです。
定期処理はcronなどで実行されていることがあります。
現在設定されているcronを確認する場合は、
crontab -l
などを利用できます。
システム全体の定期処理については、cron以外にsystemd timerなどが使われている場合もあります。
ディスク容量が少ない場合は別の確認も必要
I/O問題を調べている途中でディスク容量がほとんど残っていないことが分かった場合は、容量不足についても確認してください。
df -h
さらに、どのディレクトリが容量を使っているか確認する場合は、
du -sh /*
などを利用できます。
ただし、I/Oが高い問題と容量不足の問題は別です。
容量に余裕があるのにI/Oだけが高い場合もあるため、df -hだけでは原因を判断できません。
サーバーが遅いときの確認順
ディスクI/Oが疑われる場合は、次の順番で調べると整理しやすくなります。
1．CPUのI/O Waitを確認する
top
waの値を確認します。
2．ディスクI/Oの状態を確認する
iostat -xz 1
%utilやawaitなどを確認します。
3．I/Oを発生させているプロセスを確認する
sudo iotop
または、
pidstat -d 1
などを利用します。
4．ログを確認する
journalctl --since "30 minutes ago"
などで、異常なログが大量に発生していないか確認します。
5．定期処理を確認する
cronやsystemd timerなどで、バックアップやバッチ処理が動いていないか確認します。
6．アプリケーション・データベースを確認する
I/Oを大量に発生させているサービスが見つかったら、そのサービスのログや設定を確認します。
I/Oが高いからといってすぐにディスクを交換しない
ディスクI/Oが高いと、「ストレージが壊れているのでは？」と考えることがあります。
しかし、I/Oが高いことだけでディスク故障とは判断できません。
大量のアクセスやバックアップ、データベース処理など、正常な処理でもI/Oは高くなります。
反対に、ディスク故障が疑われる場合には、I/O以外にもエラーやSMART情報などを確認する必要があります。
つまり、
I/Oが高い＝ディスク故障
ではありません。
まず何がI/Oを発生させているのかを確認してください。
I/O問題を改善するときの考え方
原因が分かったら、その原因に合わせて対策します。
例えばログが原因なら、
- 不要なログ出力を減らす
- ログローテーションを確認する
- エラーの根本原因を修正する
などが考えられます。
バックアップが原因なら、
- 実行時間を変更する
- バックアップ対象を見直す
- 処理方法を変更する
といった対応があります。
データベースが原因なら、クエリやインデックス、データベース設定などを確認する必要があります。
ストレージ性能そのものがボトルネックなら、より高速なストレージへの変更なども選択肢になります。
重要なのは、原因に合わせて対策することです。
まとめ
Linuxサーバーが遅いとき、CPUやメモリに問題がなく、ディスク容量にも余裕があるなら、ディスクI/Oを確認してみましょう。
まず、
top
でwaを確認し、
iostat -xz 1
でディスクI/Oの状態を確認します。
その後、
sudo iotop
やpidstatなどを使って、どのプロセスがI/Oを発生させているのかを調べます。
ログ、バックアップ、Docker、データベースなどが原因になることもあるため、I/Oの数値だけで判断しないことが重要です。
「ディスク容量が足りない」のか「ディスクへの読み書きが集中している」のかを分けて考えると、サーバーの遅延原因をより正確に切り分けられます。
ディスク容量に余裕があるのにLinuxが遅いのはなぜですか？
ディスク容量とディスクI/Oは別の問題です。
大量のログ、データベース処理、バックアップなどによってディスクへの読み書きが集中すると、容量に余裕があっても処理が遅くなることがあります。
I/O Waitが高いと何が問題ですか？
CPUがI/O処理の完了を待っている時間が増えている可能性があります。
ただし、一時的な処理でも上昇するため、継続して高い状態なのか確認してください。
iostatが使えない場合はどうすればいいですか？
iostatがインストールされていない可能性があります。
Linuxのディストリビューションに合わせてsysstatなど必要なパッケージを導入してください。
ディスクI/Oが高いときはサーバーを再起動すれば直りますか？
一時的に改善する可能性はありますが、原因が解決するとは限りません。
ログ、バックアップ、データベース、アプリケーションなど、I/Oを発生させている処理を確認することが重要です。