Linuxサーバーのリソース監視 — top/htopでボトルネックを見つける
本記事はアフィリエイト広告（A8.net）を含みます。価格・仕様は2026年6月時点の目安です。最新は各公式サイトでご確認ください。
TL;DR
サーバーが「遅い」「落ちる」という状況に直面したとき、原因をあてずっぽうに探すと時間を消耗します。リソース監視の要点はCPU・メモリ・ディスクI/O・ネットワークの4層を順番に確認し、どの層が詰まっているかを絞り込むことです。
top または htop でCPUとメモリの概況を掴み → free でスワップの有無を確認し → iostat/df でディスク I/O とディスク使用率を確認し → ss/iftop でネットワークの状態を見る、という順序が実務上のショートカットです。本記事ではそれぞれのコマンドの読み方と、よくあるボトルネックのパターンを整理します。
なぜリソース監視が必要か
Webアプリやバッチ処理が突然遅くなる理由は複数あります。CPUが限界に達している場合もあれば、メモリが枯渇してスワップに頼っている場合も、ディスクI/Oが詰まっている場合も、ネットワーク帯域の問題である場合もあります。
ログを見ても原因が分からないとき、多くの場合はリソースの枯渇が起きています。 アプリケーションレイヤーのデバッグより先に、OS側のリソース状態を確認するのが効率的な切り分けの順序です。外形監視（死活監視）との組み合わせについてはウェブサイト死活監視ガイドも参照してください。
① CPU — top / htopでロードアベレージを読む
topの基本表示
top はほぼすべてのLinuxディストリビューションに標準で入っているプロセスモニタです。
top起動すると次のようなヘッダが表示されます。
top - 14:22:01 up 12 days, 3:45, 2 users, load average: 0.52, 0.38, 0.41
Tasks: 112 total, 1 running, 111 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.2 us, 1.1 sy, 0.0 ni, 95.1 id, 0.3 wa, 0.0 hi, 0.3 si, 0.0 st
MiB Mem : 1975.6 total, 213.4 free, 1201.7 used, 560.5 buff/cache
MiB Swap: 1024.0 total, 788.2 free, 235.8 used. 773.9 avail Memロードアベレージの読み方
load average: 0.52, 0.38, 0.41 の3つの数値は、それぞれ直近1分・5分・15分の実行待ち（ランキュー）プロセス数の平均です。
重要なのはCPUコア数との比較です。
| コア数 | load average が “正常” の目安 | 要注意ライン |
|---|---|---|
| 1コア | 1.0 未満 | 1.5 超 |
| 2コア | 2.0 未満 | 3.0 超 |
| 4コア | 4.0 未満 | 6.0 超 |
コア数は nproc または lscpu で確認できます。
nproc
lscpu | grep "^CPU(s):"load average がコア数を大きく上回っている状態が続く場合は、CPUがボトルネックになっている可能性があります。ただし、1分値が高くて15分値が低ければ一時的なスパイクであり、逆に1分・5分・15分すべてが高ければ慢性的な過負荷です。
%Cpu行の読み方
| 項目 | 意味 |
|---|---|
us | ユーザー空間プロセスのCPU使用率 |
sy | カーネル（システムコール）の使用率 |
id | アイドル（余裕がある状態） |
wa | I/O待ち（ディスクやネットワークの応答待ち） |
st | 仮想化ホストに奪われた時間（VPS環境で出ることがある） |
wa が常時 10〜20% を超えている場合は、CPUが詰まっているのではなくディスクI/Oが原因である可能性が高いです（→ ④で確認）。
htopの利点
htop は top の視覚的な上位互換です。インストールされていなければ追加します。
sudo apt install htop -y
htophtop での操作ポイントは次の通りです。
F6でソートのキーを変更（CPU・メモリ・PIDなど）F5でツリー表示（親子プロセスの関係が分かる）F3でプロセス検索F9でシグナル送信（Kill含む）F4でフィルタリング
CPUバー（コアごとの使用率）が一目で分かるため、マルチコア環境での偏りの確認に便利です。
② メモリ — free・スワップ・OOM
freeコマンド
free -h出力例：
total used free shared buff/cache available
Mem: 1.9Gi 1.2Gi 213Mi 22Mi 560Mi 773Mi
Swap: 1.0Gi 236Mi 788Miavailable の列が実際に新しいプロセスが使える見込みのメモリ量です。free より大きいのは、buff/cache（ファイルキャッシュ）がメモリ圧迫時に解放されるためです。available が 100MB を切り始めたら要注意です。
スワップの状態確認
スワップ（Swap used）が増えているとき、システムはメモリが不足してディスクへの読み書きを行っています。ディスクはメモリより桁違いに遅いため、スワップの増加はシステム全体のレスポンス低下に直結します。
スワップの詳細なIN/OUT（単位時間あたりのスワップ出し入れ）は vmstat で確認できます。
vmstat 1 5出力の si（swap in）と so（swap out）の列を確認します。常時ゼロでなければスワップが頻繁に発生しています。
OOM（Out of Memory）の確認
メモリが完全に枯渇するとLinuxカーネルのOOM Killerがプロセスを強制終了します。Webサーバーのプロセスが突然死んでいる場合、OOM Killerが原因であることがあります。
sudo dmesg | grep -i "oom"
sudo journalctl -k | grep -i "killed process"Out of memory: Killed process 1234 (nginx) のようなメッセージが出ていれば、メモリ不足が原因です。
③ ディスク — df・du・iostat・I/O待ち
ディスク使用率（df）
ディスクが満杯になるとログの書き込みもDBの更新もできなくなり、サービスが停止します。
df -h出力例：
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 50G 43G 4.2G 92% /
tmpfs 988M 0 988M 0% /dev/shmUse% が 85〜90% を超えたら早急な対処が必要です。 ルートパーティション満杯の場合はSSHログイン自体できなくなることもあります。
大きなディレクトリの特定（du）
どこが容量を食っているかを絞り込みます。
du -sh /var/log/*
du -sh /home/* | sort -rh | head -20sort -rh で人間可読形式（-h）の大きい順（-r）にソートします。ログローテーションが機能していないと /var/log が肥大化しやすいです。
I/O待ちの確認（iostat）
iostat は sysstat パッケージに含まれています。
sudo apt install sysstat -y
iostat -xz 1 5-x で拡張統計、-z でアクティビティのないデバイスを省略します。1 5 は1秒間隔で5回取得する指定です。
注目する列は次の通りです。
| 列 | 意味 | 目安 |
|---|---|---|
%util | デバイスが使用中の割合 | 80% 超が継続 → 飽和 |
await | I/Oリクエストの平均待ち時間（ms） | HDD: 数十ms、SSD: 数ms |
r/s, w/s | 1秒あたりの読み/書きリクエスト数 | 環境依存 |
%util が 80〜100% で張り付き、await が異常に高い場合はディスクI/Oがボトルネックです。このとき top の wa も高くなっている場合、I/O待ちがCPUをブロックしている状態です。
④ ネットワーク — ss・iftop
接続状態の確認（ss）
netstat は非推奨です。現在は ss を使います。
ss -tulpnオプションの意味：-t（TCP）-u（UDP）-l（待ち受け中）-p（プロセス名）-n（名前解決しない）。
ss -sss -s でTCPの状態サマリを表示します。TIME-WAIT や CLOSE-WAIT が異常に多い場合は接続が適切に閉じられていない可能性があります。
特定ポートへの接続数を確認する場合：
ss -tn state established | grep ':80' | wc -l帯域使用量の確認（iftop）
sudo apt install iftop -y
sudo iftop -nどのIPとの通信が多いかをリアルタイムで確認できます。予期しない外部への通信がある場合、マルウェアや設定ミスによるデータ流出の兆候である可能性があります。
⑤ プロセスの特定
ボトルネックの層が分かったら、原因プロセスを特定します。
CPUを最も使っているプロセス
top で P キーを押すとCPU使用率順にソートされます。htop では F6 → PERCENT_CPU でも同様です。
ps aux --sort=-%cpu | head -10メモリを最も使っているプロセス
ps aux --sort=-%mem | head -10特定プロセスのI/Oを確認（pidstat）
sysstat に含まれる pidstat でプロセス単位のI/Oを確認できます。
pidstat -d 1-d でディスクI/O統計を表示します。特定プロセスを絞る場合は -p <PID> を追加します。
プロセスが開いているファイルとポート（lsof）
sudo lsof -p <PID>
sudo lsof -i :<ポート番号>⑥ 継続監視への発展
単発コマンドによる確認は障害発生時に有効ですが、事前に異常を検知するには継続的なメトリクス収集が必要です。
watchによる簡易定期実行
watch -n 5 'free -h && echo "---" && df -h'-n 5 で5秒ごとに更新します。簡単な定点確認に便利ですが、ターミナルを閉じると止まります。
/proc ファイルシステムの活用
Linuxのリソース情報は /proc 以下のファイルとして公開されています。スクリプトから定期取得する場合に使えます。
cat /proc/loadavg # ロードアベレージ
cat /proc/meminfo # メモリ詳細
cat /proc/diskstats # ディスクI/O統計本格的な監視スタック
運用規模が大きくなると、top や free での手動確認には限界があります。メトリクスを蓄積・可視化するツールを導入すると過去の傾向分析や異常アラートが可能になります。
| ツール | 概要 |
|---|---|
| Prometheus + node_exporter | Linuxのシステムメトリクスを収集・蓄積 |
| Grafana | Prometheusのデータを可視化・ダッシュボード化 |
| Netdata | エージェント1つでリアルタイム可視化（セットアップが軽い） |
死活監視・外形監視についてはウェブサイト死活監視ガイド、VPS初期設定についてはVPS初期セキュリティハードニングも参照してください。
まとめ
| 確認項目 | コマンド | 注目ポイント |
|---|---|---|
| CPU / ロードアベレージ | top, htop | load average がコア数超 / wa が高い |
| メモリ / スワップ | free -h, vmstat 1 | available 低下 / si,so が継続 |
| OOM | dmesg | grep oom | プロセス強制終了の痕跡 |
| ディスク使用率 | df -h | Use% 85% 超 |
| 大容量ディレクトリ特定 | du -sh + sort -rh | /var/log の肥大化 |
| ディスクI/O | iostat -xz 1 | %util 80% 超 / await 異常値 |
| ネットワーク接続 | ss -tulpn, ss -s | 接続数・CLOSE-WAIT 異常 |
| 帯域使用量 | iftop -n | 予期しない外部通信 |
| CPU使用プロセス特定 | ps aux --sort=-%cpu | 上位プロセスの確認 |
| メモリ使用プロセス特定 | ps aux --sort=-%mem | 上位プロセスの確認 |
| プロセス単位I/O | pidstat -d 1 | 特定プロセスのI/O負荷 |
障害対応の基本順序は「CPU → メモリ → ディスクI/O → ネットワーク」の4層を上から確認することです。top の wa が高ければディスクへ、free の available が低ければメモリへ、と手がかりが連鎖的に現れます。単発コマンドで状況を掴んだ後、継続監視のスタックを整えることで事前に異常を検知できる体制に移行できます。
各サービス公式
リソース監視の練習や本番環境の構築には、スペックとコストのバランスが取れたVPSが適しています。どちらもUbuntu/Debianのテンプレートから即座に起動できます。
- ConoHa VPS: 時間課金で短期検証から利用しやすく、コントロールパネルからのコンソールアクセスが緊急時に役立ちます。
- Xserver VPS: 高クロックなCPUと安定した国内データセンターが特徴で、本番運用向けの安定性があります。
VPS選定の詳細な比較は法人向けVPSレンタルサーバー比較にまとめています。