5 ステップで効率的に問題箇所を絞り込む — サーバー別の症状と対策、よくある質問、シリーズ総まとめ。
ボトルネックを効率よく特定するには、全体 → 詳細 の順で確認します。最初から特定のリソースを深堀りすると、別のサーバーが根本原因だったというケースを見逃しがちです。
アクセスログ — いつ・どの URL が遅いかを特定
レスポンスタイムが悪化している時刻・URL を特定する。この「いつ」が他サーバーのデータと対照する基準になる。
vmstat — 全体状況確認（r / b / si / so / wa）
問題の時刻帯に r（実行待ち）・b（I/O 待ちブロック）・スワップ・wa が上昇していないか確認する。
mpstat — CPU の詳細確認（%idle / %iowait）
CPU がボトルネックかどうかを確認。%iowait が高い場合は CPU 問題ではなく I/O 問題の可能性が高い。
iostat — ディスク I/O 確認（%util / await）
%util が高い・await が長い場合はディスクがボトルネック。DB サーバーで特に重点確認する。
free — メモリ確認（available / Swap）
available が枯渇・スワップ増加が見られる場合はメモリ不足。特に APL サーバーの GC 頻度にも注意。
| 症状 | 考えられる原因 | 対策の方向性 |
|---|---|---|
| レスポンスタイム上昇 | APL/DB が遅い（Web 自体は正常） | APL・DB サーバーを優先確認 |
| CPU 使用率が高い | SSL 処理・大量同時接続 | SSL オフロード・ロードバランサー検討 |
| 5xx エラーが増加 | APL サーバーが過負荷・タイムアウト | タイムアウト設定見直し・APL スケール |
| 症状 | 考えられる原因 | 対策の方向性 |
|---|---|---|
| CPU が継続的に高い | ロジックの非効率・スレッド不足 | プロファイリング・スレッドプール調整 |
| メモリが増加し続ける | メモリリーク・GC 不足 | ヒープダンプ解析・GC ログ確認 |
| DB 待ちが長い | N+1 クエリ・インデックス不足 | スロークエリログ確認・SQL 改善 |
| 症状 | 考えられる原因 | 対策の方向性 |
|---|---|---|
| ディスク I/O が高い（%util 高） | フルスキャン・バッファプール不足 | インデックス追加・バッファプール増量 |
| await（待機時間）が長い | ディスク飽和・書き込み集中 | SSD 化・RAID 見直し・I/O 分散 |
| CPU は低いが遅い | ロック競合・I/O 待ち | ロック競合確認・クエリチューニング |
Q. vmstat の最初の行がおかしい？
最初の行はシステム起動からの累計値です。2 行目以降を分析対象にしてください。
Q. free の free 列が少なくても問題ない？
はい。「available」列を重視してください。buff/cache は必要時に解放されるため、free が少なくても available が十分あれば正常です。
Q. 収集間隔・時間の目安は？
5 秒間隔でテスト中 10〜30 分間収集するのが一般的です。負荷テストのシナリオに合わせて調整してください。
Q. 複数サーバーのデータをどう比較する？
各サーバーのデータを「時刻」でそろえてから比較します。性能劣化が始まった時刻に他サーバーで何が起きていたかを確認します。NTP での時刻同期が前提です。
Webシステム性能評価ガイド（全5回）の要点を振り返ります。