事象
service:app-benkyo が動作するホスト host:ap にて、CPU使用率がほぼ100%に張り付く事象が発生。
DB接続先の修正後も改善せず、Bits AI Chat を活用して調査を進めた結果、複数のプロセス管理の問題が連鎖していたことが判明・解決した。
環境
- ホスト: 1台のAPサーバー（
host:ap）に複数のNode.jsアプリが同居 - プロセス管理: PM2
- アプリ: Express + MySQL（ポート3004でリッスン）
- 環境:
env:dev
調査・対応の経緯
フェーズ1：DB接続先IPの誤り（※別検証のため故意に設定）
症状: app-benkyo からMySQLへの接続がタイムアウトし、HTTPリクエストが500エラーを返す。
原因: .env ファイル内の DB_HOST が誤ったIPアドレスを指していた。
対応: 正しいDB接続先IPに修正し、アプリを再起動。
結果: DB接続エラーは解消したが、CPU使用率は100%のまま改善せず。
→「あれ？故意に設定していたDBのIPアドレス誤りが真因ではないの？」
フェーズ2：CPU100%の真因 — Bits AI Chatに質問
CPU使用率が改善しないため、APMサービスページからBits AI Chatに「nodeのエラーが頻発している理由は？」と質問。
Bits Chatの自動分析:
- APMスパン検索を即座に実行し、直近1時間に 2,151件のエラー を検出
- 全エラーが同一パターンであることを特定: PM2の
ProcessContainerFork.jsがexit_code: 1で異常終了 - ソースコードリポジトリを自動参照し、エラー発生箇所を特定
- 「ポート競合によるクラッシュループ」と診断
Bits Chatのアドバイスに従いサーバーで確認:
PM2のステータス:
│ 6 │ app-benkyo │ 1.0.0 │ fork │ 0s │ 403… │ online │ 50% │ 49.1mb │
-
uptime: 0s— 起動直後にクラッシュ -
↺: 403…— 400回以上再起動 - CPUが高いのは、起動→クラッシュ→再起動を毎秒繰り返していたため
エラーログ:
TypeError: Cannot read properties of null (reading 'port')
at Server.<anonymous> (/home/ito/app/app-api.js:273:53)
ポート使用状況:
$ ss -tlnp | grep 3004
LISTEN 0 511 *:3004 *:* users:(("node /home/ito/",pid=3818553))
→ 別のプロセスが既にポート3004を占有していた。
原因: 同じスクリプト /home/user/app/app-api.js がroot側のPM2で app-benkyo として登録されていたが、先に別のプロセスがポート3004を占有していたため、app-benkyo は毎回起動に失敗していた。
対応: PM2から重複していた app-benkyo プロセスを削除。
結果: CPU使用率が正常に低下。（100％→48%）
→ 「よかった～。正常に低下した。でもあれ？Nodeサービスの方でエラー頻発していない？」
フェーズ3：nodeサービスでエラーが頻発 — Bits Chatが原因を特定
症状: service:node の command_execution オペレーションで毎時約2,150件のエラーが継続発生。
Bits Chatの分析:
APMスパン検索で全エラーが同一パターンであることを確認：
- コマンド:
node /usr/local/lib/node_modules/pm2/lib/ProcessContainerFork.js - 終了コード:
exit_code: 1 - 発生間隔: 約1.7秒ごと
Bits Chatのアドバイスに従いサーバーで確認:
$ ps aux | grep node
ito 3818553 ... node /home/ito/app/app-api.js ← itoユーザーのPM2が管理
root 1581601 ... node /home/ito/app/app-api.js ← rootユーザーのPM2が管理
根本原因（Bits Chatの診断）:
PM2はユーザーごとに独立したプロセスリストを持つ。ito ユーザーのPM2と**root ユーザーのPM2**の両方が同じスクリプトを同じポートで起動しようとしていた。
ito のPM2 → node /home/ito/app/app-api.js → ポート3004 ✓（先に起動、占有）
root のPM2 → node /home/ito/app/app-api.js → ポート3004 ✗（競合→即死→再起動ループ）
対応:
# itoユーザーのPM2プロセスを停止・削除
su - ito
pm2 stop /home/ito/app/app-api.js
pm2 delete /home/ito/app/app-api.js
pm2 save
# root側のapp-benkyoが正常起動を確認
pm2 list
# → app-benkyo: uptime 100s+、status: online、mem: 85.6mb ✓
結果: エラー数が毎時2,150件 → ほぼ0件に改善。CPU使用率も 48%→6% ほどに。
Bits AI Chatが役立ったポイント
| 活用場面 | Bits Chatの貢献 |
|---|---|
| エラーパターン分析 | APMスパン2,151件を即座に検索し、原因を特定 |
| 根本原因の診断 | ポート競合 → null参照 → クラッシュループという因果関係を論理的に説明 |
| 具体的な手順提示 |
ss、ps、pm2 logs など確認すべきコマンドを提示アプリケーションログをとっていなくてもここをみればよいということを提示してくれる |
教訓
1. PM2はユーザーごとに独立して動作する
-
rootと一般ユーザーで別々のPM2プロセスリストが存在する - 同じスクリプトを複数ユーザーのPM2に登録するとポート競合が発生する
- 管理は1ユーザーに統一する
2. クラッシュループはCPU使用率を跳ね上げる
- プロセスの起動→クラッシュ→再起動が高速で繰り返されると、CPU使用率が100%に張り付く
- PM2ステータスの
uptime: 0sと高い再起動回数（↺）はクラッシュループの明確なサイン
3. Bits AI Chatはトラブルシュートの強力なパートナー
- APMデータの検索・分析、ソースコードの参照、具体的なコマンドの提示まで一気通貫で対応
- ふわっとした自然言語での指示でもＯＫ
- 調査結果を伝えれば次のステップを的確にアドバイスしてくれる
注意
Bits AIは8月から有料になります。
料金形態は年間支払い、月間支払い、オンデマンドの3つが存在。
使いすぎには注意。