サーバーが重くなった瞬間に迷わず動けるよう、高負荷時の初動対応をCPU・メモリ・I/O・コネクション別に最短ルートで整理します。
目的は「まず叩くコマンド」と「切り分けの観点」を即時に判断し、復旧と恒久対策につなげることです。
本記事ではLinuxコマンドを活用した方法を解説していきます。基本的な Bash についての知識が必要になります。Bashについて不安がある方はこちらも参考にしてください → Bash
詳細な流れを横断的に確認したい場合は Linuxトラブルシューティング総合ハブ から全体像をご覧いただけます。
高負荷時にまず確認すべきこと
最初に大切なのは「利用者に影響が出ているか」を確認することです。アラートやログだけに気を取られると、実際のサービス応答を見落としがちです。応答速度が遅くなっていないか、エラー画面が出ていないかをブラウザやアプリから直接確かめましょう。
次に監視ツールや uptime コマンドで、直近の負荷上昇が一時的か継続的かを確認します。特にロードアベレージの急上昇は、CPUに限らずI/O待ちやメモリ不足でも発生します。そのため「何が原因で上がっているのか」を後続の確認で切り分けていく必要があります。
この時点では、まだ手を加える必要はありません。まずは症状とリソース変動の記録を残すことが、後で恒久対策を検討する際の大きな助けになります。
CPU負荷の確認と初動対応
CPUの高負荷が疑われる場合、最初に使うべきは top です。top を実行するとロードアベレージやCPU使用率、メモリ使用状況まで一度に確認できます。あわせて uptime を叩けば、直近1分・5分・15分のロードアベレージの推移が分かり、一過性のスパイクか長期的な高止まりかを判断できます。
もしCPUが高止まりしているなら、次はプロセス単位での切り分けです。
ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | headを使えば、CPUを最も消費しているプロセスが即座に分かります。htop が導入されている環境なら、より直感的にプロセス別負荷やコアごとの使用状況をリアルタイムで追跡できます。
ここでポイントとなるのは「本来CPUを使うべき処理かどうか」です。バッチ処理やビルドなど想定どおりの負荷なら待つだけで済むこともありますが、アプリケーションの無限ループや暴走プロセスであれば即座に停止対応を検討する必要があります。
メモリ逼迫の確認と初動対応
メモリの状態を確認するには、まず free -m を叩きます。ここで空きメモリが極端に少なく、スワップ領域の使用が増えていれば逼迫のサインです。より詳細に見る場合は vmstat 1 5 を実行し、ページングやスワップの発生状況を継続的に観察します。
スワップが活発に使われている場合、ディスクI/Oが増えて応答速度が大幅に低下します。どのプロセスがメモリを占有しているのかを切り分けるには、
ps -eo pid,ppid,cmd,%mem --sort=-%mem | head で上位プロセスを洗い出すと有効です。
初動対応としては、不要なプロセスの停止や、キャッシュクリアを試みるのが現実的です。ただし闇雲にプロセスを落とすのではなく、サービス影響を最小限に抑えることが優先です。アプリケーションのメモリリークや設定ミスが原因なら、一時的に解放しても再発するため、後続で恒久的な修正を検討する必要があります。
I/O負荷の確認と初動対応
CPUやメモリに異常がなくても、ディスクI/Oが詰まっていると全体の処理が重くなります。
まず
iostat -x 1 5 を実行し、ディスク利用率（%util）や待ち時間（await）が高騰していないかを確認します。値が常に80%以上を示す場合、I/Oがボトルネックになっている可能性が高いです。
より詳細に見るなら iotop が有効です。どのプロセスが大量の読み書きを行っているのかをリアルタイムで把握でき、問題箇所の特定に直結します。特にログ出力の暴走やバックアップ処理がI/Oを占有していないかを切り分けるのが第一歩です。
I/O負荷が高いときの落とし穴は、ディスク容量逼迫です。空き容量が不足すると書き込みエラーや応答遅延が発生し、負荷がさらに悪化します。もしログファイルの肥大が原因なら、ローテーションや削除で速やかに対応します。詳細な手順は［ディスク逼迫の初動対応］を参照してください。
コネクション逼迫の確認と初動対応
サーバーが「重い」と感じられるとき、CPUやI/Oではなくネットワークコネクションの逼迫が原因となるケースも多いです。まず ss -s を実行して全体の接続数や状態を把握しましょう。TIME_WAIT や ESTABLISHED が急増していれば、アプリケーションや外部からのアクセス集中が疑われます。
より詳細に確認するには netstat -antp | head や ss -ant を使い、特定ポートへの接続数や同一IPからの大量アクセスを洗い出します。ここで特定のプロセスに紐づいている場合は、負荷元のサービスを明確にできます。
もし特定のIPから異常な数の接続がある場合は、攻撃や誤設定の可能性があります。その場合は一時的に iptables や firewalld で遮断する対応も選択肢に入ります。ただし恒久的には、アプリケーション側のコネクション管理や同時接続数の制御を見直す必要があります。
ネットワーク関連ではポート競合や不要プロセスが原因になることもあるため、併せて［ポート競合の解消手順］を確認しておくと安心です。
まとめ：高負荷時に再現性を残す行動
高負荷対応で最も重要なのは、ただ切り分けて一時対応するだけでなく、再現性のある記録を残すことです。
top -b -n 1 > /tmp/top.logや
vmstat 1 10 > /tmp/vmstat.logのように、負荷時の状態を保存しておけば、後で原因を精査できます。ログやスクリーンショットでも構いませんが、時刻付きで残すことが大切です。
また、監視閾値の見直しも欠かせません。今回の高負荷が想定外だったのか、アプリケーションの利用増加による必然だったのかを振り返り、恒久対策に繋げます。スケールアップやキャッシュ導入など、中長期の施策を検討する材料になります。
Linuxトラブルシューティングの全体像 を確認すれば、今回の初動対応を他のトラブルと関連付けて整理できます。高負荷の初動対応は「切り分け」がすべてです。
あわせて［ディスク逼迫の初動対応］や［ポート競合の解消方法］も参考にしてください。
高負荷時に落ち着いて状況を記録し、切り分けを積み重ねることで、次回はより迅速かつ安全に対応できるようになります。
参考リンク
- 「Linux でディスクが満杯になった原因を特定する方法」 — LinuxConfig による解説記事 (LinuxConfig)
- 「Linux でポート競合を検出し解決する方法」 — Labex のチュートリアル (LabEx)
- 「Linux のネットワークトラブルシューティングに使うコマンドまとめ」 — Codilime ブログ (CodiLime)
- 「ポートバインディングエラーのトラブルシューティング」 — Alibaba Cloud 技術記事 (Alibaba Cloud)
- 「10 Ways to Check Ports in Linux」 — TechRepublic 記事 (TechRepublic)
