サーバー更改後に性能が落ちた時の切り分け

URLをコピーしました！

サーバー更改後に、

処理が遅くなった
レスポンスが悪化した
ピーク時に詰まりやすくなった

という相談は非常に多く、

「スペックは上がっているのに遅い」

というケースも珍しくありません。

本記事では、

更改後に性能が落ちる典型パターン
切り分けの正しい順番
どこまで確認すれば原因特定と言えるか

を実務視点で整理します。

切り分けの大原則

性能劣化が起きたときに最も重要なのは、

「旧サーバーとの差分」を基準に考えること

です。

更改後サーバー単体を見ても、

CPUが低負荷
メモリも余っている

というケースは多く、誤診しやすいためです。

① 本当に性能が落ちているかを確認

まずは主観ではなく、

処理時間
レスポンス時間
スループット

が実際に悪化しているかを確認します。

OK判断： 数値として旧環境より悪化している

② CPU性能の切り分け

確認コマンド

top
mpstat

見るポイント

user / system が張り付いていないか
iowait が高くないか

注意： CPU idle が高くても遅いケースは多い

③ メモリ・スワップの切り分け

確認コマンド

free -m
vmstat 1

見るポイント

swap が使われ始めていないか
si / so が増えていないか

OK判断： スワップが常用されていない

④ ディスクI/Oの切り分け

確認コマンド

iostat -x 1

見るポイント

%util が張り付いていないか
await が旧環境より増えていないか

よくある原因：

ストレージ種別変更
I/Oスケジューラ差分

⑤ ネットワーク性能の切り分け

確認コマンド

ss -s
ip -s link

見るポイント

再送（retransmission）の増加
drop エラー

注意： MTU 不一致や仮想NIC差分が原因のことが多い

⑥ カーネルパラメータ差分

確認例

sysctl -a | grep net.

重要：

旧サーバーでチューニングしていたか
デフォルトに戻っていないか

⑦ アプリケーション起因の確認

更改時に、

ミドルウェアのバージョン変更
設定初期化

が入っていることがあります。

OK判断： 旧環境と同等設定で動作している

⑧ 仮想環境特有の落とし穴

vCPU割当方式の変更
NUMA 構成差分
ストレージ共有度合い

物理性能は上でも、実効性能が下がることがあります。

切り分けの正しい順番まとめ

本当に性能が落ちているか
CPU / メモリ / I/O のどこか
旧環境との差分
設定か設計か

「原因特定できた」と判断する基準

差分を説明できる
元に戻す or 調整で改善する
再発防止策が言語化できる

まとめ

更改後の性能劣化は珍しくない
単体ではなく差分で見る
順序立てた切り分けが最短

焦って設定をいじる前に、

「どこが変わったか」を整理する

これが最も重要です。