徹底解説:Linuxの top コマンド — 原理・見方・実践的運用とトラブルシューティング

はじめに

topコマンドは、Unix/Linux環境でリアルタイムにプロセスとシステムのリソース使用状況を監視するための代表的なツールです。インタラクティブな操作でソートやフィルタリング、プロセスの終了や優先度変更(renice)などが行え、障害対応や性能確認でまず起動されることの多いコマンドです。本稿ではtopの動作原理、各フィールドの意味、主要オプション、現場での使い方、注意点、他ツールとの比較まで深掘りして解説します。

topの基本表示と見方

topを起動すると画面上部にシステム全体のサマリ(ロードアベレージやCPU/メモリの合計使用率など)、下部にプロセス一覧が表示されます。代表的なフィールドの意味は次の通りです。

  • PID:プロセスID。
  • USER:プロセス所有ユーザー。
  • PR:プロセス優先度(priority)。
  • NI:nice値。プロセスのスケジューリング優先度に影響。
  • VIRT:仮想メモリサイズ(プロセスが参照するアドレス空間の合計)。ライブラリやmmap領域、未割り当て領域、スワップも含む。
  • RES:実メモリ(Resident Set Size)。実際に物理メモリ上に存在するページの合計。ただし共有ページも含む。
  • SHR:共有メモリサイズ。共有ライブラリ等で他プロセスと共有されている領域の概算。
  • S:プロセス状態(R=Running, S=Sleeping, D=Uninterruptible sleep, Z=Zombie, T=Stopped等)。
  • %CPU:直近の更新間隔におけるCPU使用率の割合。SMP環境では100%が1コアを完全に使い切ることを意味し、複数コアを使えば100%を超えることがある点に注意。
  • %MEM:システム物理メモリに対するRESの割合。
  • TIME+:プロセスがCPUを使った累積時間(時刻)。
  • COMMAND:コマンド名またはコマンドライン(cキーで切替)。

上部サマリの詳細

上部のサマリ行はトラブルシューティングで重要な情報を与えます。

  • load average:1/5/15分の平均負荷。これはシステムに対して実行可能または実行待ちのプロセス数の平均で、CPUコア数と対比して評価します(例えば4コアマシンでloadが4ならフルロードに相当)。ロード平均の解釈については Brendan Gregg 等の解説が参考になります。
  • Tasks:合計プロセス数と各状態の内訳(running, sleeping, stopped, zombie)。ゾンビプロセスが増えていると親プロセスがwaitしていない/終了処理がされていない可能性があります。
  • CPU(s):各CPUや合計のユーザ時間、システム時間、nice、iowait、steal、idleなどの割合を表示。iowaitが高い = I/O待ちがボトルネックである可能性がある。
  • Mem / Swap:total/used/free/buff/cache等。ここで注意すべきはLinuxのキャッシュ/バッファの扱いで、freeコマンド等と合わせて「実際にアプリケーションが利用可能なメモリ」を判断することです。/proc/meminfoのMemAvailableフィールドはカーネル3.14以降で利用可能なより実務的な空き指標です。

主要なインタラクティブ操作(実務でよく使うキー)

  • P:CPU使用率でソート(デフォルト)。
  • M:メモリ使用率でソート。
  • T:累積CPU時間でソート。
  • k:指定PIDをkillする。SIGTERM等のシグナルを指定可能。
  • r:指定PIDのnice値を変更(renice)。
  • c:COMMAND欄をプログラム名/コマンドラインで切替。
  • H:スレッドの表示/非表示切替(スレッドを個別に見る必要があるときに有効)。
  • f:表示フィールドのオン/オフと表示順の変更。
  • o:並び順を指定。
  • s:更新間隔(秒数)を変更。
  • i:idleプロセスの表示/非表示切替(CPU使用率が0に近いものを隠す)。
  • W:現在の設定を~/.toprcへ保存。
  • q:終了。

よくある用途と実践例

以下は現場で頻出するケースとtopの活用法です。

  • CPUスパイクの調査:topを起動してPソート、更新間隔を短め(1秒)に設定し、%CPU上位のプロセスを確認する。複数スレッドで高いCPUを消費している場合はHでスレッド表示に切替える。
  • メモリリークの検出:長時間観測してRESが継続的に増加するプロセスを特定する。VIRTが大きくてもRESが増えない場合は割り当てはあるが物理メモリを使っていない可能性がある。
  • I/Oボトルネック判定:CPUは低くiowaitが高い場合、ディスクI/O待ちが発生している。iostatやiotopと組み合わせて詳細を確認する。
  • 負荷テスト時の集計:-b(バッチモード)と-n回数を使い、ログとして出力して後で解析する。シェルスクリプトで定期的にtopの出力を保存することでトレンド解析が可能。

topの計算と注意点(%CPU, メモリ等)

topの%CPUは表示更新間隔の間にプロセスが消費したCPU時間の差分(ユーザ時間 + システム時間)を経過時間で割り、100倍して表示します。マシンに複数コアがあると、複数コアを同時に使うなら100%を超える可能性があります。従って「CPU使用率が100%という表示」は“CPU 1コアをフルに使用”という意味であり、相対評価の対象はコア数です。

メモリ表示でも誤解が生じやすい点があります。Linuxは空きメモリをキャッシュ/バッファとして有効活用するため、単純なfree値だけで空きメモリが少ないと判断すると誤りです。/proc/meminfoのMemAvailableは実用的な空きメモリ指標で、topやfreeの出力と合わせて判断してください。

バッチモードとスクリプト内利用

topはインタラクティブだけでなく、-b(batch)オプションで非対話モードでの利用が可能です。監視スクリプトやログ収集で使う際は次のような使い方が一般的です。

  • top -b -n 1 -o %CPU で1回だけCPU順に出力する。
  • top -b -d 5 -n 12 で5秒毎に12回(1分間隔でのサンプル)を取得する。
  • 出力をawk/grepで加工して監視ツールに渡す(ただしtopのフォーマット変更に弱い点に注意)。

カスタマイズと設定ファイル

topは起動後のキー操作で表示フィールドや色、ソート順などをカスタマイズでき、Wキーで~/.toprcに保存できます。複数ユーザーで同じ設定を共有したい場合はこのファイルを配布すると便利です。

procfsとの関係と内部動作(概略)

topは/proc以下の情報を読み取ってプロセス情報やCPU/メモリ情報を取得します。具体的には/proc/stat, /proc//stat, /proc/meminfoなどを参照し、差分を計算して%表示を行います。したがって/procの内容が正確であり、カーネルが提供する指標に依存していることを理解しておく必要があります。

topが苦手なこと・補完ツール

  • topは詳細なI/O履歴やディスク帯域の詳細、ネットワーク利用状況の長期履歴には向かない。iotop, iostat, sar, pidstat, nethogs等と組み合わせるのが良い。
  • より使いやすいインターフェースやツリー表示が必要なら htop(対話的で視認性が高い)、長期の詳細解析なら atop、統合監視なら Glances などを使う。
  • コンテナ環境ではcgroupやnamespaceの影響でtopの見え方が変わる。コンテナ内でのtopはそのコンテナから見えるプロセスとリソースに限定される点に注意。

トラブルシューティングのワークフロー例

典型的な「突然の負荷上昇」対応の手順は次のようになります。

  1. topを起動し、P/M/Tキーでボトルネックの候補(CPU/メモリ/累積時間)を絞る。
  2. 疑わしいプロセスをpsやls -l /proc//fdで開いているファイルやソケットを確認。
  3. iowait高であればiotop/iostat、メモリ問題ならsmemやpmap、/proc//statusのVm*値も確認。
  4. 必要ならプロセスを一時停止(kill -STOP)して影響を切り分け、後でSIGTERM/SIGKILLで対応する。

よくある誤解と注意点まとめ

  • topのメモリ表示が『空きが少ない = 問題』ではない。キャッシュ/バッファを考慮すること。
  • %CPUはコア単位での相対値であり、マルチスレッドで100%超はあり得る。
  • topの出力はカーネル提供の/proc情報に依存するため、カーネルバグやprocfsの変更に影響される可能性がある。
  • バッチモードの解析はフォーマット依存なので、より安定したデータ取得が必要なら/procを直接読み取るスクリプトやpsコマンドの利用も検討する。

まとめ

topはシステム状態を素早く把握するための強力なツールです。表示内容の意味(VIRT/RES/SHRや%CPUの相対値)や、上部サマリの解釈(load averageやiowait)を正しく理解することで、トラブル発生時の初動対応や日常的な性能監視の精度が向上します。top単体で全てを解決できるわけではないため、iotop/htop/atop/ps等の補助ツールや/procの直接参照と組み合わせて使うことが重要です。

参考文献