サーバーが遅いと感じて確認すると、
- CPU idle が高い
- CPU使用率も低い
- それでもレスポンスが悪い
この状態は、 Linux運用で最も混乱しやすいパターンの一つです。
本記事では、 CPU idleが高い=正常ではない理由を整理し、 どこを見れば原因に辿り着けるのか を実務目線で解説します。
目次
結論:CPU idleが高い=CPU以外を待っている
CPU idle が高いということは、 CPUが仕事をしていない状態です。
しかしそれは、
- 処理が軽い
- 問題がない
ことを意味しません。
多くの場合、 CPU以外のリソース待ちが発生しています。
まず確認:CPUのどの時間が idle なのか
確認コマンド
top
注目ポイント
- id(idle)
- wa(I/O wait)
idleが高く、waも高い場合、 CPUはディスク待ちで暇になっています。
原因①:I/O wait が高い
最も多い原因です。
I/O wait が高い状態では、
- プロセスはCPUを使いたい
- しかしI/O完了待ちで止まっている
結果として、 CPU idle が高く見えます。
確認方法
iostat -x 1
await / %util が高ければ、 ディスクI/Oが原因です。
原因②:ディスク以外の待ち(NFS・ネットワーク)
I/O wait は、 ローカルディスク以外でも発生します。
- NFS
- iSCSI
- 外部ストレージ
これらが遅延すると、 CPUは仕事ができず idle 状態になります。
原因③:ロック待ちが発生している
CPUもディスクも空いているのに遅い場合、 ロック待ちが原因のことがあります。
典型例
- DBのテーブルロック
- ファイルロック
処理は進まず、 CPUは使われないため idle が高く見えます。
原因④:スワップ・メモリ関連の待ち
メモリ不足により、
- スワップイン・アウト
が発生すると、 CPUはI/O待ち状態になります。
確認方法
vmstat 1
si / so が増えていれば、 メモリ起因です。
原因⑤:アプリケーションの待ち状態
以下のような待ちも、 CPU idle を高く見せます。
- 外部API応答待ち
- DB接続待ち
- スレッドプール枯渇
OSではなくアプリ側の問題 であるケースです。
「CPU idleが高いのに遅い」ときの正しい切り分け順
- top で wa を確認
- iostat でディスク確認
- iotop で犯人プロセス確認
- vmstat でスワップ確認
- アプリログ・DBロック確認
解決したと判断できる状態
- wa が低下する
- レスポンスが体感で改善
- 処理待ち時間が減少
よくある誤解
- CPU idle が高い=余裕がある
- CPUが空いていれば問題ない
- niceを下げれば解決する
idle は「仕事ができない暇」 であることも多いです。
まとめ
CPU idle が高いのに遅い場合、 CPUは犯人ではありません。
重要なのは、 「CPUが何を待っているか」 を見抜くことです。
本記事の切り分け手順を使えば、 直感に惑わされず、正しい原因に辿り着けます。
あわせて読みたい


I/O waitが高い時にやるべき切り分け手順
サーバーが遅い、レスポンスが悪いと感じて調査すると、 CPU使用率は低い メモリも余裕がある しかし I/O wait(wa)が高い という状態に遭遇することがあります。 本記…
あわせて読みたい


ioniceが効かない時に確認すべきポイント
ディスクI/O負荷対策として ionice を設定したのに、 I/O wait が下がらない 業務レスポンスが改善しない 「ioniceって意味あるの?」と感じた この状況は、 ioniceの使…
あわせて読みたい


iotopの正しい使い方(犯人プロセス特定編)
ディスクI/Oが逼迫し、I/O wait が高い時、 iostat ではディスク全体の状態は分かる しかし「誰が」I/Oを出しているかは分からない そんな時に使うのが iotop です。 本…
