サーバー負荷は低いのにレスポンスが悪い時の見方

サーバー監視画面を見ると、 CPU使用率も低く、メモリも余裕がある。 それなのに、

• 画面表示が遅い
• APIの応答がワンテンポ遅れる
• SSHや管理画面の反応が悪い

このような状況に遭遇したことはないでしょうか。

本記事では、 「サーバー負荷は低いのにレスポンスが悪い」時に、どこをどう見ればよいのかを、 初心者でも順番に確認できる視点で解説します。

結論：CPUやメモリだけでは「速さ」は判断できない

結論から言うと、 サーバーのレスポンス低下はCPU負荷やメモリ使用率だけでは判断できません。

レスポンスは、

• ディスクI/O
• ネットワーク待ち
• プロセスの詰まり
• 外部サービス依存

といった 「待ち時間（レイテンシ）」の影響を強く受けます。

まず確認すべき前提（ここがズレると判断を誤る）

① 見ている「負荷」とは何か

一般的に「サーバー負荷が低い」と言う場合、 以下のどれかだけを見ていることが多いです。

• CPU使用率
• ロードアベレージ
• メモリ使用率

しかしこれらは、 「計算資源が空いているか」の指標であり、 「処理が速いか」の指標ではありません。

見るべきポイント①：ロードアベレージの中身

ロードアベレージが低くても、 レスポンスが悪いことは十分あり得ます。

なぜか

ロードアベレージには、

• CPUを使っているプロセス
• I/O待ちのプロセス

の両方が含まれます。

I/O待ちが多い場合、 CPUは暇なのに処理が進まない という状態になります。

確認方法

top

以下の項目を確認します。

• wa（I/O wait）が高くないか
• load average がCPUコア数と乖離していないか

判断基準

• wa が継続的に高い → ディスクI/O疑い
• CPU idle が高いのに遅い → 待ち時間が原因

見るべきポイント②：ディスクI/O待ち

レスポンス低下で 最も見落とされやすい原因がディスクI/Oです。

よくある状況

• ログ肥大化
• バックアップ処理中
• ストレージ性能不足

確認方法

iostat -x 1

判断基準

• %util が 80～100% に張り付く → I/O逼迫
• await が高い → レスポンス遅延

この場合、 CPUやメモリは正常でも体感は遅くなります。

見るべきポイント③：ネットワーク待ち

WebサーバやAPサーバでは、 外部通信待ちがレスポンス悪化の原因になることがあります。

代表例

• DBサーバへの通信遅延
• 外部API呼び出し
• DNS名前解決の遅延

確認方法

ss -s
netstat -an | wc -l

判断基準

• ESTABLISHED や TIME_WAIT が異常に多い
• 通信待ちが増えている

見るべきポイント④：アプリケーションの詰まり

サーバーリソースが空いていても、 アプリケーション内部で詰まっていることがあります。

例

• ワーカープロセス上限に到達
• コネクションプール枯渇
• スレッド待ち

判断のヒント

• プロセス数が上限に張り付いている
• 一部リクエストだけ極端に遅い

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

以下が揃えば、 レスポンス問題は解消したと判断できます。

• 体感レスポンスが改善している
• I/O wait が低下している
• await / レイテンシが安定している
• タイムアウトや遅延ログが消えている

実務向けチェックリスト（この順で見る）

1. CPU使用率・ロードアベレージ
2. I/O wait（wa）
3. ディスクI/O（iostat）
4. ネットワーク接続数
5. アプリケーション内部状態

まとめ

サーバー負荷が低いのにレスポンスが悪い場合、 「どこで待たされているか」を見る必要があります。

CPUやメモリだけで判断せず、

• ディスクI/O
• ネットワーク
• アプリケーション

を順番に確認することで、 原因を見誤らずに対処できます。