htop・btopでLinuxプロセス管理を極める

htopとbtopは、古くからある top コマンドをカラフルなダッシュボード・マウス操作・プロセス管理機能で置き換えるインタラクティブなプロセスモニタだ。どのプロセスがCPUを食っているのか、top の数字の壁を見て判断するより、htopやbtopなら数秒で特定できる。

htopは軽量で高速なプロセスビューア。btopはCPUグラフ・ネットワーク・ディスクI/Oを1画面に表示するフルダッシュボード。どちらもプロセスのkill、優先度変更、名前フィルタリングをターミナルから離れずに実行できる。

topだけでは足りない理由

top はLinuxに必ず入っているし、ちょっとした確認には使える。でも本番サーバーで何年も使っていると、同じストレスに何度もぶつかる：

• マウスが使えない — 操作は暗号的なキー1文字
• 横スクロールできない — 長いコマンドラインが途中で切れて見えない
• デフォルトの表示がつらい — モノクロで、CPU・メモリ・スワップの区別がつかない
• プロセスをkillするにはPIDを手入力 — 選択してkillできない

top の出力はこんな感じだ：

top - 14:32:01 up 47 days,  3:12,  2 users,  load average: 2.31, 1.87, 1.45
Tasks: 312 total,   1 running, 308 sleeping,   0 stopped,   3 zombie
%Cpu(s): 15.2 us,  3.1 sy,  0.0 ni, 80.4 id,  0.8 wa,  0.0 hi,  0.5 si
MiB Mem :  15921.4 total,   1243.2 free,   8934.1 used,   5744.1 buff/cache

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1847 www-data  20   0 1245832 234112  18432 S  45.2  1.4  12:34.56 node
 2103 postgres  20   0  987264 456320  32768 S  23.1  2.8   8:21.03 postgres

数字の壁だ。同じ情報をhtopで見ると、コアごとの色分けCPUバー、メモリゲージ、スクロールできるプロセスリストが表示される。情報量は同じなのに、認知負荷が劇的に下がる。

htop：topの進化系

htop は2004年から存在し、現在は htop-dev/htop でメンテナンスされている。バージョン3.4.1（2025年4月）でGPU監視メーターの追加とUnicode処理の改善が入った。

インストール

# Debian / Ubuntu
sudo apt install htop

# Fedora / RHEL
sudo dnf install htop

# Arch Linux
sudo pacman -S htop

# macOS
brew install htop

ほとんどのディストリビューションでデフォルトリポジトリに入っている。PPAやサードパーティリポは不要。

htopの画面構成

htop を起動すると3つのセクションが表示される：

1. ヘッダー — コアごとのCPUバー、メモリバー、スワップバー、ロードアベレージ、アップタイム、タスク数
2. プロセスリスト — ソート・スクロール可能なテーブル（PID、ユーザー、CPU%、MEM%、コマンドなど）
3. フッター — ファンクションキーショートカット（F1〜F10）

CPUバーの色には意味がある：

32blogのVPSを新規セットアップしたとき、SSH直後にまず htop を開いてベースラインを確認する。素のUbuntuサーバーならCPUバーはほぼ空、メモリは200〜400 MB程度のはず。何もデプロイしていないのにメモリが60%使われていたら、何かがおかしい。

必須キーボードショートカット

毎日使うショートカットはこれだけ：

ツリー表示（F5）はデバッグで非常に便利。Node.jsアプリが子プロセスを生成しているとき、どの親がどのワーカーを持っているかが一目でわかる。以前 ps aux | grep node で20分格闘したプロセス階層が、htopのツリー表示なら数秒で把握できた。

ヘッダーのカスタマイズ

F2 で設定画面に入ると、メーターを追加できる：

• CPU average — 全コア合計の単一バー
• Disk I/O — 読み書きスループット
• Network I/O — ネットワーク送受信（htop 3.4+）
• System load — 1/5/15分のロードアベレージ
• Hostname and clock — SSH複数セッション時に便利

僕のサーバー設定は、左にCPU（コアごと）、右にメモリ+スワップ+ロード。設定は ~/.config/htop/htoprc に保存されるので、scp で他のマシンにコピーできる。

フィルタリングとソート

メモリリークを探すときはメモリ順ソート：

# メモリ順でhtop起動
htop --sort-key=PERCENT_MEM

htop内で F6 を押して PERCENT_MEM を選ぶと、メモリ消費量順にソートされる。ステージングサーバーで PostgreSQL のコネクションリークを見つけたのもこの方法だった。47個のアイドルコネクションがそれぞれ30 MBのレジデントメモリを保持していた。

フィルタ（F4）で node や postgres と入力すると、それ以外のプロセスが非表示になる。検索（F3）と違って、フィルタはマッチしないプロセスを完全に隠すので、集中して確認できる。

btop：フルダッシュボード

btop はbashtop、bpytopの後継となるC++製ツール。htopがプロセスリストに特化しているのに対し、btopはCPUの時系列グラフ、ネットワーク帯域、ディスク活動、バッテリー状態を1つのターミナル画面に収める。バージョン1.4.6（2025年12月）ではプロセスのrenice対応とAMD CPU名の整形が改善された。

インストール

# Debian / Ubuntu (22.04+)
sudo apt install btop

# Fedora
sudo dnf install btop

# Arch Linux
sudo pacman -S btop

# macOS
brew install btop

# Snap（どのディストリでも）
sudo snap install btop

btopの画面構成

btopは画面をボックスに分割する：

• CPUボックス — コアごとの使用率バー + 時系列のローリンググラフ
• メモリボックス — RAM・スワップ使用率とグラフ
• ネットワークボックス — リアルタイムのアップロード/ダウンロード速度
• ディスクボックス — マウントされたファイルシステムごとの読み書きスループット
• プロセスボックス — ソート・フィルタ可能なプロセスリスト（htopと似た操作感）

btopに惹かれたのはCPUのローリンググラフだ。cronジョブが定期的にCPUスパイクを起こすとき、htopは「今この瞬間」のスナップショットしか見せてくれない。btopは直近数分のパターンを表示するので、「60秒ごとにスパイクが起きている」というのが一目でわかる。

キーショートカット

設定

btopの設定は ~/.config/btop/btop.conf にある。Esc → Options でGUI的に設定することもできる：

# ~/.config/btop/btop.conf（主要設定）
color_theme = "Default"
theme_background = False    # タイリングWM利用者向け透過背景
update_ms = 2000            # 2秒ごとに更新（デフォルト: 2000）
proc_sorting = "cpu lazy"   # CPU順ソート、毎フレーム再ソートしない
shown_boxes = "cpu mem net proc"  # 表示するボックス

僕はWSL2環境で theme_background = False にしている。Windows Terminalのテーマとbtopの背景が揃って見た目がすっきりする。

htop vs btop：使い分け

僕の使い分け： サーバーではhtop（軽量・高速・どこでも入る）、ローカル開発マシンではbtop（情報量が多い・グラフが便利）。512 MBのVPSでは1 MBでも惜しいからhtop一択。32 GBの開発マシンなら、btopのグラフは余裕で見合う。

プロセス操作：kill・nice・シグナル

htopでもbtopでもプロセス管理はUI上でできるが、裏で何が起きているかを理解しておくと対応の幅が広がる。

シグナル

htopで F9（kill）を押すと、実際にはプロセスにシグナルを送っている。重要なものを整理する：

まずSIGTERMを試すこと。 SIGKILLは最後の手段だ。プロセスがクリーンアップできない — 一時ファイルは残り、DBトランザクションはロールバックされず、子プロセスが孤児になる可能性がある。

コマンドラインからの操作：

# 優雅に終了
kill 1847

# 強制kill（SIGTERMが数秒効かないとき限定）
kill -9 1847

# 名前で指定してkill
pkill -f "node server.js"

# 特定ユーザーのプロセスを全部kill
pkill -u www-data

PostgreSQLを kill -9 して痛い目を見たことがある。DB自体は復旧したが、WALログのリプレイに4分かかった。SIGTERM ならPostgresはアクティブなクエリを完了してバッファをフラッシュしてから終了してくれる。

niceとrenice

すべてのプロセスには -20（最高優先度）から19（最低優先度）の nice値 がある。デフォルトは0。nice値が高いほど、プロセスは他のプロセスに「優しい」（CPU時間を譲る）。

# CPU負荷の高いタスクを低優先度で開始
nice -n 10 ffmpeg -i input.mp4 -c:v libx264 output.mp4

# 実行中のプロセスの優先度を変更
renice 15 -p 1847

# 最高優先度に設定（root権限が必要）
sudo renice -20 -p 1847

btopではプロセスを選択して r でrenice。htopでは F7（nice値を下げる＝優先度を上げる）と F8（nice値を上げる＝優先度を下げる）が使える。

実践パターン

CPUを食っているプロセスを見つけてkillする：

# htop: F6でCPU%順ソート → プロセス選択 → F9 → SIGTERM

# コマンドラインから:
ps aux --sort=-%cpu | head -5
kill $(pgrep -f "runaway-script")

ゾンビプロセスをkillする：

ゾンビは直接killできない。すでに死んでいるからだ。親プロセスをkillする必要がある：

# ゾンビプロセスを探す
ps aux | awk '$8 ~ /Z/ {print $2, $11}'

# 親PIDを確認
ps -o ppid= -p <zombie_pid>

# 親をkill（またはSIGCHLDで催促）
kill -SIGCHLD <parent_pid>

プロセス状態の読み方

htopの S カラム（btopでは State カラム）に表示される1文字が、プロセスの状態を表す。デバッグに必須の知識だ：

心配すべきパターン

D（ディスクスリープ）プロセスが多い — ディスクが圧倒されている。CPUヘッダーのI/O wait（topの wa 値）を確認。wa が20%を超えていたらストレージがボトルネック。クラウドVPSではバーストIOPSを使い切っているケースが多い。

ゾンビプロセスが増え続ける — 少数のゾンビは正常で無害（リソースはほぼ消費せず、プロセステーブルの1スロットだけ）。しかし数が増え続けるなら、親プロセスにバグがある。子プロセスの wait() を呼んでいないということだ。親を特定して再起動する。

ロードアベレージがCPUコア数より高い — 4コアのシステムで1分間のロードアベレージが12なら、プロセスがCPU待ちの行列に並んでいる。htopのツリー表示でどのプロセスツリーが原因か特定しよう。

# コア数とロードアベレージの確認
nproc              # CPUコア数
uptime             # 末尾にロードアベレージ

# load >> nproc なら犯人を探す:
htop --sort-key=PERCENT_CPU

よくある勘違いだが、ロードアベレージが高い＝CPU使用率が高い、ではない。 D 状態（ディスクスリープ）のプロセスもロードにカウントされる。CPUが低いのにロードが高い場合、ボトルネックはストレージであってコンピュートではない。

実例：htopでのデバッグ

32blogのVPSでNext.jsビルドが通常の3倍かかったときの話：

1. htop を開いてCPU順ソート — 特に異常なし、CPUは40%
2. ロードアベレージを確認 — 2コアのマシンで8.2
3. F5 でツリー表示 — node プロセスが6個（Next.jsのビルドワーカー）
4. S カラムを確認 — ほとんどが D 状態（ディスクスリープ）
5. 診断：VPSのバーストIOPSを使い切っていた。ビルドはI/Oバウンドで、CPUバウンドではなかった

修正はシンプルで、SSDバックのVPSティアにアップグレードした。htopでプロセス状態を一目で確認できなかったら、ビルド設定の最適化という間違った方向に時間を使っていたと思う。

FAQ

htopはtopより良いの？

インタラクティブな用途なら間違いなく良い。htopは色分けCPUバー、マウス操作、ツリー表示、その場でのプロセス管理を追加してくれる。topの利点はどこにでも入っていること。最小構成のコンテナやレスキューシェルではtopしか使えないこともある。

btopはSSH越しに使える？

使える。ただしターミナルがbtopのグラフで使う拡張文字セットに対応している必要がある。最近のターミナル（Windows Terminal、iTerm2、Alacritty、kitty）なら問題ない。グラフが文字化けする場合は TERM=xterm-256color を設定するか、htopにフォールバックしよう。

SIGTERMで死なないプロセスはどうする？

数秒待って（クリーンアップ中かもしれない）、それでもダメなら kill -9 <PID> またはhtopの F9 でシグナル9（SIGKILL）を選択。SIGKILLすら効かない場合、プロセスは割り込み不可のスリープ（D 状態）でカーネル操作を待っている可能性が高い。デッドNFSマウントやディスク障害が原因で、リブートが必要になることもある。

htopのVIRT、RES、SHRの違いは？

VIRT はプロセスがマッピングした仮想メモリの合計 — 共有ライブラリ、メモリマップドファイル、確保したけど未使用のメモリを含む。RES（レジデント）は今実際にRAMに載っている量。SHR はRESのうち他プロセスと共有している部分（主に共有ライブラリ）。RESに注目する のが正解。

htop・btopはmacOSで使える？

使える。Homebrewで brew install htop btop するだけ。コアごとの周波数やcgroup情報などLinux固有の機能は表示されないが、コアの監視とプロセス管理は同じように動作する。

htopを好みのソート順で起動するには？

コマンドラインオプションを使う：htop --sort-key=PERCENT_MEM でメモリ順起動。または設定画面（F2）で設定すれば ~/.config/htop/htoprc に保存される。

Dockerコンテナのプロセスをhtopで監視できる？

できる。ホスト側で htop を起動し、フィルタ（F4）でコンテナのメインプロセス名を入力。あるいは docker exec -it <container> htop でコンテナ内から起動すれば、そのコンテナのプロセスだけが表示される。

htopとbtopの更新間隔は？

htopのデフォルトは1.5秒、btopは2秒。どちらも変更可能 — htopは設定画面から、btopは +/- キーまたは update_ms 設定で調整できる。

まとめ

top は緊急時には使えるが、htopとbtopはプロセス監視を「作業」から「理解」に変えてくれる。サーバーではhtop — 軽い、速い、どこにでもある。ツリー表示だけでインストールの価値がある。ローカルマシンではbtop — CPUグラフとネットワーク監視があれば、別のツールを5つ開かなくていい。

本当の価値はきれいな色じゃない。ワークフローだ。スパイクを見て、プロセスをフィルタして、状態を確認して、シグナルを送る。ターミナルから離れず、PIDを暗記する必要もない。その筋肉記憶がつくと、今までどうやってプロセスを管理していたのか不思議になる。

次のステップ：バックグラウンドタスクのスケジュール管理には cron・systemd timerガイド を。子プロセスを生成するスクリプトのシグナルハンドリングには シェルスクリプトガイド を参照してほしい。