php-cgi 進程 CPU 狂飆根因排查與解決方案全景圖

現象描述

環境：RedHat 5.5 + Nginx + PHP-FPM。症狀：top 顯示多個 php-cgi 進程 CPU 長期佔用 90%+，負載飆升至 100+，靜態資源訪問正常，Nginx 無報錯，明確為 PHP 執行層問題。

四大典型根因及定位手段

1. 擴展兼容性陷阱：eAccelerator 與 PHP 版本不匹配

表現：啟動 10 分鐘後響應極慢，CPU 飆高。

定位：php -m | grep eaccelerator 確認已加載；對比 PHP 版本與擴展編譯版本。

解決：php.ini 註釋 extension=eaccelerator.so，改用 OPcache（PHP 5.5+ 內置）或 APCu。

2. 代碼邏輯死循環

表現：負載持續 100+，單核跑滿。

定位——利用 /proc 文件系統：

# 1. 找到高 CPU 進程 PID
ps aux | grep php-cgi | sort -k3 -nr | head -5

# 2. 查看該進程正在執行的腳本
ls -l /proc//fd/ | grep '\.php'

# 3. 追蹤系統調用（需安裝 strace）
strace -p  -s 200 -o trace.log

# 4. 分析 trace.log，尋找重複的 poll/read/write/lstat 等調用

解決：修復業務代碼邏輯（如遞歸無終止條件、while(true) 缺 break、大數據集未分頁處理）。

3. Session 濫用導致鎖競爭（記事狗微博程序實例）

表現：少量進程（<10 個）CPU 98%，負載 4-8，請求堵塞。

根因：默認 session.save_handler = files，高併發下大量進程競爭同一 Session 文件鎖（flock）。

定位：strace -p 大量 flock(..., LOCK_EX) 等待。

解決方案對比：

4. 極端耗時/不可完成操作（業務代碼缺陷）

• 無超時設置的外部 API 調用（file_get_contents/cURL 無 CURLOPT_TIMEOUT）。
• 大數據導出未分批、無異步隊列（同步生成 10 萬行 Excel）。
• 正則災難性回溯（preg_match 處理長文本）。

定位：同樣通過 strace 或 xhprof/xdebug.profiler 火焰圖定位熱點函數。

通用排查工具箱

# 實時監控 PHP 進程 CPU/內存
watch -n 1 "ps aux | grep php-cgi | awk '{print \$2,\$3,\$4,\$11}'"

# 慢日誌分析（需開啟 php-fpm slowlog）
tail -f /usr/local/php/var/log/slow.log | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | sort | uniq -c | sort -nr

# 火焰圖生成（需安裝 perf + FlameGraph）
perf record -g -p  -- sleep 30
perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > php-flame.svg

預防體系建設

1. 代碼審查機制：禁止裸露 set_time_limit(0)、強制外部調用設置超時。
2. 預發環境壓測：模擬生產流量，觀察 CPU/內存/慢日誌曲線。
3. 運行時保護：PHP-FPM 配置 request_terminate_timeout = 30s、request_slowlog_timeout = 5s。
4. 監控告警：Prometheus + Grafana 監控 php_fpm_cpu_usage、php_fpm_active_processes，閾值觸發鉤子自動重啟 Worker 池。

總結

php-cgi CPU 狂飆本質是**代碼層面的資源失控**。從擴展兼容、死循環、Session 鎖、異步缺失四個維度切入，配合 /proc、strace、slowlog、火焰圖工具鏈，可實現「分鐘級定位、小時級修復」。長遠看，建立「開發規範 → 壓測驗證 → 運行時守護 → 監控閉環」的工程化體系才是治本之策。