【第5回】Linuxプロセス管理とリソース監視の極意！サーバーの悲鳴を可視化せよ

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
「Linuxエンジニアになるための基礎」連載、第5回へようこそ。前回はユーザー管理とアクセス制御（IAM）による、サーバー内部の要塞化について学びました。

今回は、インフラエンジニアにとって最も痺れる瞬間である「障害対応（トラブルシューティング）」の最前線、「プロセス管理とリソース監視」について、圧倒的な情報密度でお届けします。サーバーが「重い」「応答しない」といった悲鳴を上げているとき、内部のCPUやメモリで何が起きているのかをレントゲンのように透視し、原因を特定して沈静化させるプロの技術を徹底解剖します。

---

第1章：Linuxにおける「プロセス」の概念とPID

サーバー上で実行されているプログラムのことを、Linuxでは「プロセス（Process）」と呼びます。Nginxも、MySQLも、あなたが叩いているBashシェルも、すべて独立したプロセスとして動いています。

1-1. PID（プロセスID）と階層構造

Linuxカーネルは、起動したプロセスを管理するために、それぞれに一意の番号である PID（Process ID） を割り当てます。そして重要なのは、プロセスは必ず「親プロセス」から生み出されるというツリー構造（階層構造）を持っていることです。

• PID 1 の絶対的君主： AlmaLinux 9などのモダンなOSが起動した直後、最初に立ち上がるプロセスが systemd（PID: 1）です。他のすべてのプロセスは、この systemd を先祖として枝分かれしていきます。
• PPID（Parent Process ID）： プロセスを生み出した「親」のIDです。親プロセスが終了（死滅）すると、子プロセスも基本的には道連れになります。

---

第2章：psコマンドによるプロセスのスナップショット

「今、この瞬間にどんなプロセスが動いているか」を写真のようにパシャリと切り取るのが ps（Process Status）コマンドです。オプションの組み合わせ方には「BSD形式（ハイフンなし）」と「System V形式（ハイフンあり）」が混在しており、初学者が混乱しやすいポイントです。

2-1. プロの標準装備：ps aux

現場でインフラエンジニアが息をするように叩くのが ps aux です。システム全体で動いているすべてのプロセスを、詳細なリソース使用量とともに表示します。

ps aux

項目	意味とプロの着眼点
USER	プロセスを実行しているユーザー。意図しないroot権限で動いているサービスがないかチェック。
PID	プロセスID。killコマンドで強制終了させる際に必要となるターゲット番号。
%CPU / %MEM	CPUとメモリの使用率。ここで異常な数値を出しているプロセスが諸悪の根源。
VSZ / RSS	仮想メモリサイズと、実際に割り当てられた物理メモリ（RSS）の量。メモリリーク調査の鍵。
STAT	プロセスの状態。R（実行中）、S（スリープ）、D（割り込み不可のI/O待ち）、Z（ゾンビ）など。
COMMAND	実行されたコマンドと引数のフルパス。

2-2. 階層関係を可視化する：ps auxf / ps -ef

プロセスが「誰の子として動いているか」をツリー状に可視化したい場合は、f (forest) オプションを追加します。NginxやApacheのような、1つのマスタープロセスが複数のワーカー（子）プロセスを生み出すアーキテクチャの確認に極めて有用です。

# プロセスの親子関係をツリー状（罫線付き）で表示
ps auxf

# System V形式を好むエンジニアはこちら（機能はほぼ同じ）
ps -ef

2-3. grepとの連携とプロのワンライナー

何百とあるプロセスから、目的のプロセス（例えば Nginx）だけを抽出したい場合は、第2回で学んだパイプ（|）と grep を組み合わせます。この時、grep コマンド自体もプロセスとしてヒットしてしまうのを防ぐのがプロの小技です。

# Nginxのプロセスを探すが、grep自身のプロセスは除外する
ps aux | grep nginx | grep -v grep

# 【プロの代替手段】pgrepコマンドを使えばよりスマート
pgrep -l nginx

---

第3章：topコマンドとロードアベレージの真実

ps が「写真」なら、top コマンドは「動画」です。サーバーのリソース使用状況をリアルタイム（数秒ごとの更新）で監視し、負荷の高いプロセスをランキング形式で表示します。

top

top を起動した際、画面上部に表示されるサマリー情報こそが、サーバーの健康状態を示すバイタルサインです。

3-1. 絶対に理解すべき「ロードアベレージ（Load Average）」

top の1行目の右端に表示される load average: 0.50, 1.20, 1.80 という3つの数値。これはそれぞれ「直近1分、5分、15分」の「CPUの処理待ちをしているプロセスの平均数」を示しています。

3-2. CPUステータスの読み解き方（wa と id）

top の3行目（%Cpu(s)）には、さらに詳細な内訳が表示されます。

• us (user): ユーザープロセス（PHPやNginxなど）が消費しているCPU。
• sy (system): カーネルプロセス（OS内部の処理）が消費しているCPU。
• id (idle): 何もしていない（空き）状態。ここが0%に近いとCPUリソースが完全に枯渇している。
• wa (iowait): ディスクI/O（読み書き）の完了を待っている時間。ここが高い場合、CPUの性能ではなく「ストレージ（HDDやSSD）の速度」がボトルネックになってサーバーが遅延しています。

3-3. topコマンド操作のプロのショートカット

top の実行中に以下のキーを押すことで、並び順を動的に変更し、犯人を特定します。

# top実行中にキーボードで入力
M (Shift + m) : メモリ使用率（%MEM）の高い順にソートする
P (Shift + p) : CPU使用率（%CPU）の高い順にソートする (デフォルト)
1 (数字の1)   : CPUのコアごとの詳細な使用率を展開表示する
c             : COMMAND列をフルパスと引数まで詳細に表示する
q             : topを終了する

---

第4章：メモリ管理の極意とOOM Killerの恐怖

サーバー障害の7割以上は「メモリの枯渇」に起因します。CPUが100%に張り付いてもレスポンスが遅くなるだけで済みますが、メモリが枯渇するとLinuxは自己防衛のためにOOM Killer（Out of Memory Killer）という死神を発動させます。

4-1. OOM Killer とは何か？

システムの物理メモリとスワップ（仮想メモリ）の全てを使い果たした時、Linuxカーネルはシステム全体のクラッシュを防ぐため、独断で「メモリを大量に消費しているプロセス」を見つけ出し、無慈悲に強制終了（kill）させます。
この際、対象が本番稼働中のMySQLデータベースであろうと容赦なく殺されるため、データ破損という致命的なインシデントに直結します。

4-2. free コマンドによる正しいメモリの読み方

メモリの残量を確認するには free コマンドを使用します。

# 人間が読みやすい単位(MB, GB)でメモリ状況を表示
free -h

# 【出力例】
               total        used        free      shared  buff/cache   available
Mem:           7.6Gi       1.2Gi       500Mi       100Mi       5.9Gi       6.1Gi
Swap:          2.0Gi          0B       2.0Gi

---

第5章：killコマンドとシグナル（SIGTERM vs SIGKILL）

暴走してCPUやメモリを食い潰しているプロセス（犯人）を top や ps で特定したら、次はそのプロセスを終了させます。
ここで使うのが kill コマンドですが、単に「殺す」だけのコマンドではなく、正確にはプロセスに対して「シグナル（信号）」を送るためのコマンドです。

5-1. 絶対に覚えておくべき3つのシグナル

番号	名前	役割と動作
15	SIGTERM (Terminate)	【デフォルト】「終了してください」という安全な終了要求。プロセスはデータを保存し、不要なファイルを掃除してから綺麗に終了します。（推奨）
9	SIGKILL (Kill)	「問答無用で今すぐ死ね」という強制終了。プロセスは後片付け（メモリ解放やDBのトランザクション完了）を一切できずに死ぬため、データ破損のリスクが極めて高い。
1	SIGHUP (Hangup)	主にデーモン（バックグラウンドサービス）に対して、「設定ファイル（.conf）を再読み込みして」と伝えるための合図として使われます。

5-2. 段階的なプロセスの終了手順

プロのインフラエンジニアは、焦っていきなり kill -9 を打つことは絶対にありません。データベースなどに打つと、インデックスが破損して復旧不可能になるからです。

# ステップ1：安全な終了要求（SIGTERM=15）を送る。番号指定なしの場合は自動で15になる。
kill 1234  # (PIDが1234の場合)

# ステップ2：しばらく待っても終了しない（プロセスが応答不能に陥っている）場合のみ、最終手段の強制終了を撃つ。
kill -9 1234

5-3. killall / pkill による一括処理

Nginxのように、1つのマスターと複数のワーカープロセスが動いている場合、PIDを1つずつ指定してkillするのは非効率です。プロセス「名」を指定して一網打尽にするコマンドが用意されています。

# Nginxという名前のプロセスをすべて終了させる
sudo killall nginx

# または
sudo pkill nginx

---

第6章：【実践】負荷急増時のプロの初動調査フロー

ここまでの知識を統合し、冒頭のコウ君が直面した「Webサーバーの応答が極端に遅い」というアラートを受けた際の、インフラエンジニアの正しい初動調査のフローをまとめます。

# 1. サーバー全体の俯瞰（ロードアベレージとCPU/メモリ状況の把握）
top
# → Shift+M または Shift+P でソートし、リソースを食い潰しているプロセスのPIDをメモする。

# 2. メモリとスワップの枯渇状況（available）を確認する
free -m

# 3. 過去にOOM Killerが発動していなかったか、カーネルのログ（dmesg）を検索する
dmesg -T | grep -i oom-killer
# または
journalctl -k | grep -i oom-killer

# 4. 特定した重いプロセスの詳細（親や引数）を確認する
ps auxf | grep [プロセス名またはPID]

# 5. 原因の特定ができたら、プロセスを「安全に」終了させて負荷を下げる
sudo kill -15 [PID]
# (プロセスが終了しない場合は sudo kill -9 [PID] )

# 6. アプリケーションのログ（NginxやPHPのエラーログ）を確認し、根本原因（バグや攻撃）を特定する
sudo tail -f /var/log/nginx/error.log

安易な再起動（リブート）に逃げず、この「証拠保全」と「原因特定」のプロセスを踏むことこそが、エンジニアとしての市場価値を決定づけます。

---

総まとめ：見えないリソースを可視化する力

第5回「プロセス管理とリソース監視の極意」、いかがだったでしょうか。
インフラの障害対応とは、暗闇の中で目隠しをして爆弾処理をするようなものです。しかし、今回学んだコマンドを懐中電灯として使えば、サーバーの内部構造を明るく照らし出すことができます。

• ps auxf でプロセスの全体像と親子関係を把握する。
• top コマンドでロードアベレージを正しく評価し、CPUステータス（id, wa）からボトルネックがCPUかディスクかを切り分ける。
• free -h で「available」の数値を確認し、OOM Killerの影に怯えないようにする。
• kill コマンドはシグナル送信ツールであり、最終手段の kill -9 以外は、プロセスに敬意を払って安全な終了（SIGTERM）を促す。

これらのコマンドを素早く正確に叩けるようになれば、深夜の障害対応でもパニックにならず、冷静沈着にシステムを復旧させる頼もしいインフラエンジニアになれるはずです。

次回、第6回は「サービス管理とデーモン（systemctl）」です。プロセスを毎回手動で起動・終了させるのではなく、OS起動時に自動で立ち上げ、死んだら自動で再起動させる「モダンなインフラ自動化の心臓部」である systemd について深く掘り下げていきます。お楽しみに！リナックス先生でした！