「サーバが遅い」と言われた時、闇雲に設定をいじる前に、まず「どこがボトルネックか」を見極めるのが先です。基本の考え方をまとめます。
ボトルネックは4つのどこか
サーバの性能問題は、たいてい次の4つのどれかです。
- CPU: 計算が詰まっている
- メモリ: 足りずにスワップしている
- ディスクI/O: 読み書きが追いつかない
- ネットワーク: 帯域や遅延で詰まる
まず「どのリソースが限界か」を測るのが出発点です。
見るコマンド
top / htop … CPU・メモリ・プロセス全体
vmstat 1 … CPU・メモリ・スワップの推移
free -h … メモリとスワップ
iostat -x 1 … ディスクI/O（%util が100%近いと詰まり）
sar … 各種リソースの履歴
ss -s … コネクション状況
CPUの見方
- ロードアベレージがコア数を大きく超えていたら過負荷
%us（ユーザー）が高い→アプリ処理、%sy（システム）が高い→カーネル/IO、%wa（IO待ち）が高い→ディスクがボトルネック
%wa が高い時は、CPUではなくディスクを疑います。
メモリの見方
- 空きが少なくても、キャッシュ分は再利用できるので即問題ではない
- スワップが使われ、増え続けているなら、メモリ不足で性能劣化のサイン
ディスクI/O
iostat -xの%utilが常に100%近い、await（応答時間）が大きい → ディスクが限界- 対策: 速いディスク（SSD/NVMe）へ、I/Oの多い処理の見直し、RAID構成の見直し
チューニングの原則
- 測ってから直す: 推測で触らない。ボトルネックを特定してから。
- 1つずつ変える: 複数同時に変えると、何が効いたか分からない。
- 変更前後で比較: 数値で効果を確認する。
よくある落とし穴
- CPUだと思っていたら、実はディスクI/O待ち（
%wa）だった - メモリを足せば直ると思ったら、原因はアプリのクエリだった
ボトルネックの誤認は、無駄なチューニングを生みます。
まとめ
パフォーマンスチューニングは「まず測ってボトルネックを特定、1つずつ直して数値で確認」が鉄則です。CPU/メモリ/ディスク/ネットワークのどれが限界かを、top・vmstat・iostat で見極める。ここを飛ばして設定をいじるのが、一番の遠回りです。