Linuxサーバーで「htop」コマンドを使ってCPUやメモリを消費するスクリプトを特定する方法

Linuxサーバー運用時、htopコマンドはCPUやメモリを過剰に消費するスクリプトやプロセスをリアルタイムで特定するための、最も手軽で使いやすい監視ツールです。htop画面ではCPU%、MEM%、PID、USER、TIME+、COMMANDなどのカラムを確認することで、PHP、Python、Node.js、cron、データベースやシステムプロセスのどれがリソースを圧迫しているか一目で把握できます。プロセスの所有者やファイルパス、目的をチェックし、安全に対応することが可能です。

共有サーバー、VPS、専用サーバーなど、どの環境でも突然の遅延の多くは制御されていないスクリプトやプロセスが原因です。例えば、バグのあるWordPressプラグイン、無限ループに陥ったPHPファイル、重いcronジョブ、最適化されていないデータベースクエリ、乗っ取られたWebファイルなどが短時間でCPU使用率を100%近くまで押し上げることがあります。メモリ消費が増えると、サービスが停止したり、MySQL接続が切れたり、Webサイトが503エラーを返したり、LinuxカーネルのOOM Killerがプロセスを強制終了する場合もあります。

本記事ではhtopのインストールから画面の読み方、CPU・メモリを消費するスクリプトの特定方法、PIDからファイルパスの確認、プロセスへの安全な対応方法まで一歩ずつ解説します。さらにセキュリティ疑惑、cron管理、ログ解析、再発防止の具体的な最適化ポイントも取り上げます。頻繁にリソース制限の問題が発生する場合は、インフラ選定も見直して、VPSサーバーパッケージや高性能ウェブホスティングのページも参考にしてください。

htopとは？topコマンドより便利な理由

htopはLinuxシステムで稼働中のプロセスをインタラクティブに監視できるターミナルツールです。従来のtopコマンドと似ていますが、より見やすいUI、カラー表示によるリソース状況、柔軟な並べ替え・検索・フィルタ・プロセス管理機能が特徴です。特にサーバー障害発生時の素早い初期診断にはhtopが第一選択となるケースが多いです。

htopでリアルタイムに以下の情報を取得できます：

• 各プロセスごとのCPU使用率
• 各プロセスごとのメモリ使用率・使用量
• プロセスのPID（プロセスID）
• プロセスを実行しているユーザー名
• コマンドラインやスクリプト名
• 稼働時間や優先度
• ロードアベレージ、全体メモリ、swap、CPUコアごとの使用率

特にホスティング環境では複数サイト・ユーザー・サービスが並行稼働するため、単なる総リソース消費だけでなく「どのユーザー／どのサイト／どのcron／どのスクリプトが原因か？」を突き止める必要があります。Linuxサーバーのhtopコマンドは、迅速な初期診断を可能にします。

htopのインストール方法（ディストリビューション別）

多くの最新Linuxディストリビューションではhtopが初期インストールされていないこともあります。rootまたはsudo権限がある場合、数秒で導入できます。新規サーバーではパッケージリストの更新後にインストールするとエラーを減らせます。

Ubuntu/Debian系サーバーの場合

以下のコマンドを使用します：

sudo apt update

sudo apt install htop -y

インストール後はhtopと入力すれば起動します。もしsudo権限がなければ、ホスティング会社に依頼してください。VPSなら通常はroot権限が付与されます。

AlmaLinux、Rocky Linux、CentOS、RHEL系の場合

RHEL系ではdnfまたはyumのどちらかを使用します：

sudo dnf install htop -y

古いCentOSではEPELリポジトリが必要：

sudo yum install epel-release -y

sudo yum install htop -y

インストール後、htopと入力するとカラー表示の監視画面が出ます。サーバー管理初心者なら、基本的なLinuxコマンドについてはLinuxコマンドガイドも参考になります。

htop画面の読み方：各カラムの意味

htop起動時、画面上部にはCPUコアごとの使用率、メモリ、swap、タスク数、スレッド数、ロードアベレージ、稼働時間が表示されます。下部にはプロセス一覧が並びます。特定時によく利用されるカラムは以下の通りです。

注意点として、瞬間的なCPU急上昇は必ずしも問題とは限りません。例えばバックアップや画像最適化、キャッシュ削除、アクセス増加時にはCPUが短時間高くなることがあります。問題なのは、同じプロセスが数分間高負荷で居座り、ロードアベレージがコア数を大きく上回り、Webサービスが応答不能になるケースです。

htopでCPU消費スクリプトを特定する方法

CPUを消費するスクリプトを見つけるには、htop画面でF6キーで並び替え項目を選ぶか、CPU%カラムで並べ替えます。マウス対応端末ならCPU%をクリックでもOK。最上位のプロセスが現在最もCPUを使っています。

ステップ1：CPU%で並び替え

CPU使用率順でプロセスを並べ替えます。php-fpm, php, python3, node, java, mysqld, bashなどが常に上位なら、そのプロセスを記録します。シングルコアなら100%が上限ですが、マルチコア環境では200%や400%も表示されます（複数コア利用中の意）。

ステップ2：PIDとUSERを記録

怪しいプロセスのPIDとUSERを控えます。例えばPID 24819、USERがsiteuser、COMMANDがphp /home/siteuser/public_html/wp-cron.phpなら、そのWebサイトのcronやWordPress機能が原因の可能性が高いです。COMMANDが短過ぎる場合はhtop設定で全コマンド表示を有効化するか、psコマンドで詳細を確認できます。

ステップ3：実際のコマンドを確認

PIDから詳細コマンドを見るには：

ps -fp PID

例：

ps -fp 24819

これでスクリプトの実行ファイルが分かります。php /home/ユーザー/public_html/index.phpならアクセスによるWebリクエスト、php /home/ユーザー/public_html/wp-content/plugins/不明プラグイン/task.phpならプラグイン由来の問題を示します。

ステップ4：ファイルパスとオープンファイルを確認

lsofコマンドでプロセスが開いているファイルやライブラリ、ログ、ネットワーク接続を確認：

lsof -p PID

この出力で、どのサイトディレクトリが稼働中か把握できます。例えば /home/example/public_html/wp-content/uploads 内で怪しいPHPが動いていれば、セキュリティ侵害の兆候です。この場合、プロセス停止だけでなくファイル除去、パスワード変更、プラグイン更新、ウイルススキャンが必要です。SSLや安全な接続構築についてはSSL証明書ソリューションも参考になります。

htopでメモリ消費スクリプトを特定する方法

メモリ問題はCPUよりも気づきにくい場合があります。CPU急上昇は即時遅延を感じますが、メモリ枯渇ではサービス終了やswap多用、サーバー全体のレスポンス低下が起きます。htop画面でMEM%カラム順に並べ替えて、最もメモリを消費しているプロセスを確認します。

MEM%、RES、Swapの関係を理解する

htopではMEM%が標準表示されます。場合によってはVIRT、RES、SHRなども表示されます。RAM分析ではRESが最重要で、実際に物理メモリを消費している量です。VIRTは仮想メモリで、必ずしも実消費ではないので注意。

例えば4GB RAMのVPSで単一PHPプロセスが900MBのRESなら異常です。Node.jsアプリが200MBから1.5GBまで増加する場合はメモリリークを疑います。MySQLやMariaDBの高RAM消費はキャッシュ用途なら正常な場合もあるため、クエリ性能やバッファ設定、全体メモリ状況を総合的に判断してください。

メモリ消費スクリプトの典型的な原因

• 無限ループに陥ったPHP/Python/Node.jsコード
• 巨大なCSVやXML、JSONファイルを一度にメモリ展開
• 最適化されていないWordPressプラグインやテーマ機能
• 画像処理、PDF生成、動画変換など重い処理
• キャッシュ不足による繰り返し重いクエリ
• ボット攻撃など同一スクリプトの多重実行
• メモリリークを起こす長時間稼働のバックグラウンドサービス

こうした場合、killコマンドでプロセスを止めても一時しのぎです。根本解決にはスクリプトの内容、入力値、なぜメモリ解放されないかを解析する必要があります。

htopでの検索・フィルタ・ツリー表示活用

サーバー上で百件以上プロセスが動いている場合、手作業で探すのは困難です。htopはF3検索、F4フィルタ、F5ツリー表示といった便利なショートカットを提供します。ツリーは親子関係を可視化でき、例えばnginxやApache配下のphp-fpm workerや、cron起動スクリプト、supervisor管理のNode.jsサービスが分かりやすくなります。

実用的なフィルタ例

• phpでPHPプロセスのみ表示
• pythonでPythonスクリプトのみ抽出
• wp-cronでWordPress cron動作を確認
• nodeでNode.jsアプリをチェック
• ユーザー名で単一ホスティングアカウントのプロセス表示

これらフィルタは特にマルチユーザー環境で時間短縮に有効です。同一サーバーで30サイトが稼働している場合、USERカラムとコマンドパス併用で問題のアカウントを即特定できます。ドメイン管理を簡単にしたい時はドメイン検索と登録も参考にしてください。

怪しいPIDへの安全な対応手順

リソース消費プロセスを発見すると、ついkill -9で即終了したくなります。しかしこの方法はデータ損失や途中の書込み失敗、サービス不整合の原因となることも。より安全な対応手順を踏みましょう。

1. プロセスを記録

PID、USER、COMMAND、CPU%、MEM%、稼働時間を記録し、htop画面のスクリーンショットも取っておきましょう。繰返し発生時の比較や、顧客・社内報告にも役立ちます。

2. ファイルパスを確認

ps -fp PIDやlsof -p PIDでファイルパスを特定。Webルートなら該当アプリのログを調査します。WordPressならwp-content/debug.log、Webサーバーならaccess log、error log、PHP-FPMならslow logがヒントになります。

3. まず通常終了を試す

暴走プロセスはまず以下で終了を試みます：

kill PID

数秒待ち、htop画面で消えているか確認。消えない・サーバー障害が深刻なら最終手段として：

kill -9 PID

kill -9はプロセスに後処理の猶予を与えず強制終了するため、DBやファイル操作、バックアップ時は慎重に。

4. 再起動する場合は発生源を調査

終了しても即再起動する場合、cronやsystemdサービス、supervisor、Webリクエストやbotが原因です。cronはcrontab -l、サービスはsystemctl status サービス名、Webトラフィックはaccess logで調べます。WordPressのwp-cronが原因ならcron設定やキャッシュ方針を見直しましょう。

htopの調査結果をログと組み合わせる

htopは「何がリソースを消費しているか」を示し、ログは「なぜ消費しているか」を教えてくれます。両者を合わせないと診断は不十分です。例えばhtopでphp-fpmが180%CPUでも、どのURLやbotがトリガーかはaccess logなしでは分かりません。

調査すべきログ例：

• Webサーバーaccess log：アクセス集中URLの特定
• Webサーバーerror log：PHPエラーや権限・500エラーの把握
• PHP-FPM slow log：遅いPHPファイル・関数の特定
• MySQL slow query log：重いSQLクエリの検出
• auth log/secure log：不審なログイン試行
• cron log：スケジュールジョブの実行タイミング確認

例えばhtopで高CPU消費PIDが、同時刻にaccess logで/wp-admin/admin-ajax.phpへ大量リクエストを受けていれば、問題はプラグイン・bot・設計ミスのAJAX処理が疑われます。この場合WAF（Web Application Firewall）やレート制限、キャッシュ・プラグイン最適化も必要です。サイト全体のパフォーマンス向上についてはウェブサイト速度最適化も参考にしてください。

正常負荷と障害負荷の見分け方

高いリソース使用＝障害とは限りません。サーバー性能、トラフィック量、アプリ種別、メンテ作業なども考慮が必要です。例えば2コアVPSでロードアベレージが6〜8を長時間維持すれば危険ですが、16コア専用サーバーなら同値でも正常です。ロードアベレージは必ずコア数とセットで解釈しましょう。

この比較で不要なパニックと本当の障害を区別できます。特にECサイトのキャンペーン時や決済・在庫連携では一時的なリソース増加が起こりますが、ユーザー体験を損なう場合はアプリ最適化とサーバー増強をセットで検討しましょう。

セキュリティ疑惑：リソース消費スクリプトはマルウェアの可能性も

CPUやメモリを消費するスクリプトが必ずしも単純なバグとは限りません。乗っ取られたサイトではスパム送信、仮想通貨マイニング、プロキシ経由のアクセス、DDoSボット、バックドアスクリプトが動いていることも。htop画面で想定外ユーザーで稼働する不審コマンド、ランダム名ファイル、/tmpなどから実行されるバイナリ、public_html/uploads内で動作するPHPは重大なセキュリティリスクです。

怪しい兆候

• COMMANDに意味不明・ランダム文字列のファイル名
• /tmp, /dev/shm, uploadsディレクトリから稼働するファイル
• 本来不要なperl, python, bashプロセス
• 外部ネットワーク接続を多発するプロセス
• 同一ユーザーで短時間に多数プロセス起動
• Webファイルの直近で不正な変更履歴

この場合、プロセス停止前に可能な限り証拠となるコマンド出力を保存。その後ファイル権限チェック、マルウェア隔離、全パネル・CMSパスワード変更、プラグイン・テーマ・コア更新、ウイルススキャンを実施。管理画面には二要素認証導入と不要な書き込み権限撤廃で長期的リスクを減らしましょう。

障害再発防止のベストプラクティス

htopで問題特定は重要ですが、再発防止こそ価値があります。以下の対策でLinuxサーバーのCPU・メモリ由来の障害を大幅に減らせます。

• PHPのmemory_limit, max_execution_time, pm.max_childrenはサーバー性能に合わせて設定
• WordPress, Joomla, 独自開発でもキャッシュ機構を導入
• 不要なプラグイン・テーマ・モジュールは削除
• MySQL slow query logで重いクエリを最適化
• cronジョブは同時刻に集中させず、分散して実行
• bot対策としてレート制限、robots.txt、ファイアウォール設定
• アプリログは定期的にローテーション、巨大ログによるdisk・RAM負荷監視
• サーバーメトリックは障害時だけでなく定期的にチェック

最適化後もリソース消費が高い場合、ソフトだけでなくインフラの問題も考えられます。アクセス増加、アプリ拡張、既存ホスティングプランの限界など。こうした場合はスケーラブルなVPSや追加RAM、高速NVMeディスク、専用リソース型サーバーが有効です。ニーズ分析にはホスティングパッケージや法人向けサーバーソリューションの比較もおすすめします。

実例：WordPressサイトでCPU急上昇のケース

4コア・8GB RAMのVPSで複数WordPressサイトが稼働。ユーザーから「サイトが遅い」「502エラーが出る」と報告。htopを開くとロードアベレージ12、全CPUコアが高負荷、同一ユーザーのphp-fpmプロセス多数。

F4でユーザー名をフィルタ。CPU消費プロセスのPIDを記録。ps -fp PIDでphp-fpm workerを確認し、lsof -p PIDで /home/site/public_html/wp-content/plugins/example-importer/import.php へのアクセスを発見。access logを見ると管理者リクエストや繰返しAJAX呼出しが同時刻に発生している。

対応としてimport処理の停止、プラグインのスケジュール設定解除、大量データの分割インポート、PHPのmax_execution_time調整、wp-cronからシステムcronへの移行を実施。結果、ロードアベレージは12→1.8に低下、CPU使用率も正常化、Web応答速度が大幅改善。htop単体ではなくpsやlsof、ログ解析を組み合わせることで根本解決が可能な例です。

htop利用時によくあるミス

• 最上位プロセスの停止だけで根本原因調査を怠る
• VIRT値を実メモリ消費と誤認
• MySQLのキャッシュ目的RAM消費を即障害扱い
• kill -9を最初から使う
• ログ確認せずアプリやユーザーを責める
• ロードアベレージをCPUコア数と無関係に解釈
• セキュリティ疑惑時にファイル整合性を無視

これらを避けることで障害対応時間の短縮や誤対応によるデータ損失リスク減少につながります。システム管理では正確な診断が迅速な対応より重要です。

よくある質問（FAQ）

Linuxサーバーでhtopコマンドは何のために使いますか？

htopコマンドは、稼働中プロセスのCPU・メモリ・ユーザー・PID・コマンド情報をリアルタイム表示します。これにより、リソースを多く消費するスクリプトを迅速に特定できます。

htopでCPU消費スクリプトをどう見つけますか？

htop画面でCPU%カラム順に並べ、長時間上位にいるプロセスのPIDとUSERを記録。ps -fp PIDやlsof -p PIDでスクリプトのパスや実行内容を確認します。

RAM消費分析ではMEM%かVIRTどちらを重視？

MEM%と特にRES値が重要です。VIRTは確保された仮想メモリ量で、必ずしも実際のRAM消費ではありません。

リソース消費プロセスはkill -9ですぐ止めるべき？

基本的にはNO。まずプロセス内容を記録し、ファイルパスを確認、通常のkill PIDを試してから。kill -9はプロセスが終わらず、サーバー障害が深刻な場合の最終手段です。

htopで高CPU使用＝攻撃の兆候？

必ずしもそうとは限りません。バックアップやインポート、キャッシュ生成、アクセス増加でもCPUは上昇します。ただしランダム名ファイル、/tmpやuploads内スクリプト、想定外ユーザーのプロセスはセキュリティ疑惑です。

まとめ：LinuxサーバーでhtopコマンドはCPUやメモリを消費するスクリプト特定の迅速・実用的な出発点です。最良の結果にはhtop情報とPID解析、lsof出力、cron管理、ログ解析を組み合わせることが不可欠です。リソース問題が頻発する場合はソフト最適化とインフラ容量の両面から評価し、必要に応じてHostragonsのホスティング・VPS・SSLソリューションを比較・検討し、用途に合った最適な構成を選択してください。