宝塔8.x/9.x开启PHP-FPM慢日志需手动修改www.conf三行：slowlog设绝对路径且目录可写，request_slowlog_timeout设5s，request_terminate_timeout保持0；改后必须重启php-fpm服务。
PHP-FPM 慢日志怎么开（宝塔 8.x / 9.x）
宝塔默认不开启 PHP-FPM 慢日志，必须手动配置才能捕获执行超时的 php 脚本。关键不是“点开关”，而是改对 www.conf 里的三行配置，并确保日志路径可写。
-
slowlog = /www/wwwlogs/php_slow.log—— 必须指定绝对路径，且/www/wwwlogs/目录需对www用户可写 -
request_slowlog_timeout = 5s—— 设为5s比较实用；设太小（如1s）会导致日志爆炸，太大（如30s）可能漏掉真凶 -
request_terminate_timeout = 0—— 建议保持为0（不限制），否则慢日志还没写完进程就被强杀了，日志为空
改完后必须重启对应 PHP 版本的 php-fpm 服务（不是重载），否则配置不生效。可在宝塔「软件商店 → PHP → 设置 → 服务」里操作，或命令行执行 systemctl restart php-fpm-80（数字按实际版本替换）。
怎么看慢日志里到底是哪个脚本在拖垮 CPU
慢日志本身不直接显示 CPU 占用，但会记录完整请求栈和耗时，结合 grep 和 awk 可快速定位高频、高耗时的脚本路径。注意：日志里 [pool www] 后面紧跟着的就是触发慢日志的 .php 文件绝对路径。
- 查最近 100 行最慢的请求：
tail -100 /www/wwwlogs/php_slow.log | grep -A 1 "script_filename" - 统计出现最多的脚本：
awk '/script_filename/{print $NF}' /www/wwwlogs/php_slow.log | sort | uniq -c | sort -nr | head -10 - 重点看
duration字段——如果某脚本反复出现且duration > 10s，基本就是它在死循环或调用阻塞外部接口
别只盯着 index.php，很多问题藏在 wp-cron.php（WordPress）、api.php（自建接口）、或 vendor/autoload.php（Composer 自动加载卡住）里。
立即学习“PHP免费学习笔记（深入）”；
宝塔监控大屏为什么看不到具体 PHP 脚本名
宝塔「监控大屏」里的「PHP 进程」只显示 php-fpm: pool www 这类通用进程名，不解析 CGI 请求路径。它本质是读取 ps aux 的输出，而 PHP-FPM worker 进程启动后不会动态更新命令行参数，所以无法区分具体脚本。
- 想实时看当前正在跑什么脚本，得用
strace或lsof：比如lsof -p $(pgrep -f "php-fpm: pool www" | head -1) | grep ".php" - 更稳的方式是配合
htop：按F5进入树状视图，找php-fpm子进程，再按s查看其系统调用，常能看到openat(..., "/path/to/xxx.php") - 宝塔自带的「进程管理」页面刷新频率低（默认 30 秒），且不支持按 CPU% 排序，建议直接用
top -p $(pgrep php-fpm)+ 按P排序
CPU 高但慢日志没记录？这些情况要单独排查
慢日志只记录「响应时间长」的请求，但有些 PHP 脚本 CPU 飙高却响应很快（比如密集计算、无限 for 循环、GD 图片压缩未加限制），这时慢日志完全沉默。
- 检查是否用了
imagecreatefromjpeg()加载超大图（>5MB）——该函数会吃光单核 CPU，但耗时可能不到 1s，不进慢日志 - 确认有没有
while(true)或usleep(0)类型的伪空转逻辑，这类代码会让cpu_usage拉满，但request_time极短 - 查看
phpinfo()页面里的disable_functions，如果禁了shell_exec等函数，某些采集类脚本可能 fallback 到纯 PHP 实现，导致 CPU 暴涨
真正难搞的是那种每秒生成几百个短生命周期 PHP 进程的场景——慢日志来不及写就被轮掉了，这时候得靠 perf record -e cycles -p $(pgrep php-fpm) -g -- sleep 5 抓火焰图，但宝塔界面里完全没入口，得登服务器操作。
