稼働中のプロセスを一覧で把握し、負荷原因をすばやく特定する方法

サーバーの応答が遅い、CPUが高止まりしている——そんなとき、最初にやるべきことは「今何が動いているか」を把握することです。ps aux コマンド一発で全プロセスの一覧を取得し、状態・CPU使用率・メモリ消費量をまとめて確認できます。本記事では稼働中プロセスの確認から負荷原因の特定まで、実務で即使える手順を紹介します。

まず全プロセスを一覧表示する

現在システムで動いているすべてのプロセスを確認するには、以下のコマンドを使います。

ps aux

出力例は次のようになります。

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1 169740 13208 ?        Ss   Jul30   0:05 /sbin/init
www-data  1842  2.1  1.4 512340 58420 ?        S    08:12   0:32 /usr/sbin/apache2
mysql     2105 15.3  8.2 1234560 338012 ?      Sl   08:13   3:41 /usr/sbin/mysqld
root      3201  0.0  0.0  10624  3200 pts/0    R+   10:04   0:00 ps aux

各列の意味は次の通りです。

• USER：プロセスを実行しているユーザー
• PID：プロセスID（シグナル送信やkillの際に使う）
• %CPU / %MEM：CPU・メモリの使用率
• STAT：プロセスの現在の状態（詳細は次節）
• START：起動日時
• TIME：累積CPU時間
• COMMAND：実行コマンド（フルパス）

STATコラムで異常なプロセスを見抜く

STAT列は、プロセスが今どういう状態にあるかを示します。実務でとくに重要な状態は以下です。

• R（Running）：実行中またはCPUキューに待機中。大量の R が続く場合はCPUが飽和している可能性があります。
• S（Sleeping）：割り込み可能なスリープ。イベント待ちの通常状態であり、問題ありません。
• D（Uninterruptible Sleep）：割り込み不可能なスリープ。ディスクI/OやNFSの完了を待っている状態です。D 状態のプロセスが多い場合、ストレージ側の問題を疑います。
• Z（Zombie）：子プロセスが終了したにもかかわらず、親プロセスが回収していない状態。少数なら許容範囲ですが、増え続ける場合は親プロセスのバグを確認します。
• T：シグナルで一時停止中。バックグラウンドジョブが止まっていることがあります。

ある運用現場では、夜間バッチ後に D 状態のプロセスが残り続け、朝のアクセス集中時にサーバーが応答不能になる問題が起きていました。原因はNFSマウントポイントの応答遅延であり、ps aux の STAT 列を確認することで迅速に特定できました。

CPU・メモリ消費の多い順に並べてボトルネックを絞り込む

プロセス数が多い環境では、消費量の多い順に並べ替えると原因を素早く特定できます。

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

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

リアルタイムで監視したい場合は top または htop（要インストール）が便利です。top 起動後に P キーを押すとCPU順、M キーを押すとメモリ順に切り替えられます。

# topをバッチモードで1回だけ取得してファイルに保存（ログ用途）
top -b -n 1 > /tmp/top_snapshot_$(date +%Y%m%d_%H%M%S).txt

特定プロセスだけを追いかける

Apache や MySQL など特定のサービスのプロセスだけを確認したい場合は、pgrep や grep との組み合わせが実用的です。

# プロセス名でPIDを一覧表示
pgrep -a mysqld

# ps の出力をgrepで絞り込む（grepプロセス自体を除外）
ps aux | grep '[a]pache2'

# PIDを指定して詳細確認
ps -p 2105 -o pid,ppid,user,stat,%cpu,%mem,cmd

grep パターンを [a]pache2 のように先頭文字を括弧で囲む書き方は、grep コマンド自身がヒットするのを防ぐ定石です。

特定プロセスのファイルディスクリプタや開いているポートまで調べたい場合は、PIDを使って lsof や ss と組み合わせます。

# PID 2105 が開いているファイルとネットワーク接続を確認
lsof -p 2105

# PID 2105 が使用しているポートを確認
ss -tlnp | grep 2105

systemdサービスと紐付けて原因を深掘りする

現代のLinux（Ubuntu 20.04以降・RHEL 8以降・AlmaLinux・Rocky Linux等）では、サービスは systemd が管理しています。ps でプロセスを特定したあと、対応するsystemdユニットと紐付けることで、ログの確認や再起動の操作がスムーズになります。

# 実行中のサービス一覧を表示
systemctl list-units --type=service --state=running

# PIDからsystemdユニット名を特定する
systemctl status 2105

# 該当サービスのログを直近50行確認
journalctl -u mysql.service -n 50 --no-pager

systemctl status <PID> はプロセスIDを直接渡すことができ、そのプロセスがどのユニットに属しているかを返してくれます。ps で怪しいプロセスを見つけたら、このコマンドで即座にサービス名を特定し、journalctl でエラーログを掘り下げるのが現場での標準的な流れです。

プロセス確認から切り分けまでの実務フロー

実際の現場では、以下の順序で調査を進めると効率的です。

1. ps aux --sort=-%cpu | head -11 でCPUトップ10を確認し、異常なプロセスの有無を把握する
2. STAT列が D のプロセスが多ければストレージ・NFS側を、Z が増えていれば親プロセスのバグを疑う
3. pgrep -a <name> でPIDを特定し、systemctl status <PID> でサービス名を確認する
4. journalctl -u <service> -n 100 でエラーログを追う
5. プロセスを止める必要がある場合は systemctl stop <service> を優先し、どうしても即時停止が必要なときのみ kill -15 <PID>（SIGTERM）を使う。kill -9（SIGKILL）はデータ破損のリスクがあるため最終手段とする

プロセスの状態確認は、サーバートラブルの切り分けで最初に立ち返る基本操作です。ps 単体ではなく、systemctl や journalctl と組み合わせることで、原因特定までの時間を大幅に短縮できます。