実行中プロセスの状態を確認して異常を素早く特定する手順

Linuxサーバーで「応答が遅い」「特定のプロセスが止まらない」と感じたとき、最初に確認すべきはプロセスの状態一覧です。ps aux コマンド1行で全プロセスのスナップショットを取得でき、STAT列を読むだけで異常の種類が即座にわかります。本記事ではプロセス状態の確認から異常の切り分けまでを実務順に解説します。

まず全プロセスの状態をまとめて確認する

最もよく使う確認コマンドは次の2つです。用途に応じて使い分けてください。

# BSD形式（STAT列が読みやすく、デーモン確認に向く）
ps aux

# UNIX形式（PPID列で親子関係を追いたいとき）
ps -ef

ps aux の出力例は次のとおりです。

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.1 168308 13440 ?        Ss   Jul01   0:03 /sbin/init
root         512  0.0  0.2  32768  8192 ?        Ss   Jul01   0:00 /usr/sbin/sshd
alice       1024  0.1  0.5 512000 20480 pts/0    S+   10:23   0:01 vim /etc/hosts
root        2048  5.3  1.2 819200 49152 ?        D    10:55   0:30 rsync -av /data /mnt/nfs

確認すべき主な列は STAT・%CPU・%MEM・COMMAND の4つです。STATに異常な文字が並んでいる行が、問題調査の糸口になります。

STAT列の状態コードを読む

STATは1文字目が基本状態、2文字目以降が補足フラグです。以下の対応を覚えておくと、出力を見た瞬間に状況が把握できます。

基本状態（1文字目）

R  実行中または実行可能（CPUを使用中・実行待ちキューに存在）
S  割り込み可能なスリープ（イベント待ち。通常のデーモンはここ）
D  割り込み不可スリープ（I/O待ちなど。kill -9 でも終了不可）
Z  ゾンビ（終了済みだが親プロセスが回収していない）
T  停止中（シグナルまたはデバッガにより一時停止）
I  アイドルカーネルスレッド（Linux 4.14以降で追加）

補足フラグ（2文字目以降）

s  セッションリーダー（端末を制御するデーモンに多い）
+  フォアグラウンドプロセスグループに属する
l  マルチスレッド
<  高優先度（nice値が負）
N  低優先度（nice値が正）

たとえば Ss は「スリープ中かつセッションリーダー」で、sshd や nginx など一般的なデーモンの典型状態です。S+ はフォアグラウンドで動作中のユーザープロセスを示します。D 状態が複数行にわたって並んでいる場合は、ストレージI/OやNFSなどのブロッキングが疑われます。

特定サービスの状態はsystemctlで確認する

systemd環境では、デーモンの起動状態・エラーログ・PIDを systemctl status でまとめて確認できます。ps aux と組み合わせることで、プロセスIDとサービス名の突き合わせが効率化します。

# サービスの状態確認（直近のジャーナルログも出る）
sudo systemctl status nginx

# 起動に失敗しているサービスだけ一覧表示
sudo systemctl --failed

# 特定PIDがどのサービスに属するか調べる
sudo systemctl status 2048

systemctl status の出力にはPID・メモリ使用量・直近のログが含まれます。サービスが「active (running)」なのに応答しない場合は、ps aux でそのPIDのSTATを確認し、D 状態で固まっていないか調べるのが実務上の定石です。

問題プロセスを素早く絞り込む実務パターン

CPU使用率でソートして高負荷プロセスを探す

# CPU使用率の高い順に上位10件を表示
ps aux --sort=-%cpu | head -11

ゾンビプロセスをまとめて検出する

# Zステータスのプロセスだけ抽出
ps aux | awk '$8 ~ /^Z/ {print}'

# 件数だけ確認したい場合
ps aux | awk '$8 ~ /^Z/' | wc -l

ゾンビプロセスはすでに終了しており、CPUやメモリを消費しません。ただしPIDテーブルを占有するため、大量に発生するとシステムが不安定になります。ゾンビの親プロセス（PPID列）を特定して再起動するか、アプリ側の wait() 処理を修正することが根本対策です。

D状態（I/Oブロック）のプロセスを検出する

# D状態のプロセスを抽出
ps aux | awk '$8 ~ /^D/ {print}'

# ストレージI/Oの状況を合わせて確認
iostat -xz 1 5

# カーネルメッセージでI/Oエラーを確認
dmesg | grep -E "error|timeout|reset" | tail -20

D 状態のプロセスはシグナルを受け付けないため、kill -9 でも終了できません。NFSマウントが応答していないケースや、ディスクI/Oが飽和しているケースが多く、根本はストレージ側の調査が必要です。

プロセス名からPIDを素早く特定する

# プロセス名でPIDと実行コマンドを確認
pgrep -la nginx

# 親子関係を木構造で確認（workerプロセスの構成確認に便利）
pstree -p "$(pgrep nginx | head -1)"

リアルタイムで状態変化を追う

ps aux はあくまでスナップショットです。状態が短時間で変化する問題には、watch コマンドと組み合わせるか、top / htop のインタラクティブツールを使います。

# 2秒ごとにD状態プロセスを更新表示
watch -n 2 "ps aux | awk '\$8 ~ /^D/ {print}'"

# topでCPU使用率順に表示（qで終了）
top -o %CPU

# htopがある環境では視認性が高くおすすめ
htop

ある運用現場では、定期バッチ処理の直後だけ D 状態プロセスが急増する事象が起き、watch で監視することでストレージI/Oの飽和タイミングを特定できました。スパイク的な問題には sar や atop などの記録型ツールも併用すると、事後に証跡を確認できます。

# sarで過去のCPU・I/O履歴を確認（sysstat パッケージが必要）
sar -u 1 10   # CPU使用率を1秒間隔で10回
sar -d 1 10   # ディスクI/Oを1秒間隔で10回

プロセス状態の確認は、サーバー調査の出発点です。STATの1文字を読む習慣をつけるだけで、「重い」「止まらない」「応答しない」といったトラブルの原因を、ログを掘り返す前に絞り込めるようになります。