PHP-FPM 慢请求报警运行手册：从 slowlog 到进程池参数调整

PHP-FPM 慢请求报警出现时，常见反应是先看接口日志，再猜是不是数据库慢了。但在线上值班场景里，更稳的做法是先判断 PHP-FPM 池是否被占满，再用 slowlog 找到卡住的脚本位置，最后决定是临时扩容、回滚配置，还是推动代码修复。

这篇文章按一份运行手册来写，适合 PHP 接口服务、传统后台管理系统、Nginx + PHP-FPM 部署环境。你可以直接把其中的检查项改成自己的域名、池名称和日志路径。

触发信号：先确认是不是 PHP-FPM 池在排队

慢请求报警不一定等于 PHP 代码慢。Nginx 上游超时、数据库连接池拥塞、外部接口阻塞、PHP-FPM 子进程不够，都可能让同一个接口看起来“变慢”。值班时先看三个信号：

• Nginx 访问日志中同一批接口的响应时间同时升高。
• PHP-FPM 状态页里 listen queue 持续大于 0。
• slowlog 里反复出现同一个入口脚本或同一段业务函数。

如果只有单个接口慢，优先看业务代码和 SQL。如果多个 PHP 接口同时变慢，而且 listen queue 持续增加，就要先把它当成 PHP-FPM 池容量问题处理，避免请求继续堆积。

快速判断：用状态页和 slowlog 锁定卡点

建议先确保 PHP-FPM 池开启状态页和 slowlog。下面是一段典型池配置，路径按自己的发行版调整：

; /etc/php-fpm.d/www.conf
pm.status_path = /fpm-status
request_slowlog_timeout = 3s
slowlog = /var/log/php-fpm/www-slow.log

Nginx 内部访问状态页时，可以只允许本机访问，避免把运行信息暴露到公网：

location = /fpm-status {
    allow 127.0.0.1;
    deny all;
    fastcgi_pass unix:/run/php-fpm/www.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

报警发生后，先看状态页。重点不是某一次瞬时值，而是连续几次采样的趋势：

curl -s "http://127.0.0.1/fpm-status?full" | sed -n '1,80p'

# 重点观察
# active processes
# idle processes
# max children reached
# listen queue

判断规则可以这样定：

• listen queue 持续增加：新请求正在等待空闲 PHP 子进程。
• max children reached 增长：池上限已经打满。
• active processes 接近 pm.max_children：当前池容量不足或部分请求卡住。
• idle processes 很多但接口仍慢：优先排查 Nginx、网络或下游服务。

再看 slowlog，找出耗时请求停在什么位置：

sudo tail -n 120 /var/log/php-fpm/www-slow.log

你可能会看到类似记录：

[29-Jun-2026 18:08:21] [pool www] pid 28431
script_filename = /srv/app/public/index.php
[0x00007f7a] mysqli_query() /srv/app/src/OrderReport.php:42
[0x00007f82] buildDailyReport() /srv/app/src/ReportController.php:88
[0x00007f90] handleReport() /srv/app/public/index.php:19

这条记录说明，子进程没有闲着，而是卡在报表查询。此时继续盲目增加 pm.max_children 可能只是让更多慢查询同时压向数据库。正确动作是把“池容量”和“卡点函数”分开判断。

处理步骤：分临时止血和根因修复两条线

处理动作建议分成两条线：先恢复服务，再修根因。不要把所有动作混在一次改动里，否则事后很难判断是哪一步生效。

第一步：确认当前池参数和机器余量

php-fpm -tt 2>&1 | grep -E "pm\\.|slowlog|status_path"
free -m
top -o %MEM

如果机器内存还有余量，并且状态页显示 max children reached 增长，可以临时把池上限调高一档。粗略估算方式是：

可给 PHP-FPM 的内存 / 单个 PHP 子进程平均内存 = 可承载子进程数

例如预留 3GB 给 PHP-FPM，单个子进程平均 80MB，那么 pm.max_children 不应超过 38 左右。还要给系统、Nginx、数据库客户端和后台任务留出空间。

第二步：只做一个临时参数改动

pm = dynamic
pm.max_children = 38
pm.start_servers = 8
pm.min_spare_servers = 8
pm.max_spare_servers = 16

改完先做配置检查，再平滑重载：

sudo php-fpm -tt
sudo systemctl reload php-fpm
sudo systemctl status php-fpm --no-pager

这里不建议一次性修改很多参数。比如同时调整池上限、慢日志阈值、Nginx 超时和数据库连接数，短期看可能恢复，长期会让复盘失去依据。

第三步：根因修复要看 slowlog 热点

如果 slowlog 总是落在报表查询、远程 HTTP 调用或大文件处理，池参数只能止血。根因修复可以按下面顺序推进：

• SQL 慢：补索引、缩小时间范围、拆分页或改成异步导出。
• 外部服务慢：加超时、缓存兜底、失败降级。
• 文件处理慢：改成后台任务，接口只返回任务编号。
• 锁等待慢：缩小锁范围，避免长事务包住 PHP 业务流程。

回滚路径：参数调大后怎么安全退回来

临时调大池容量不是永久方案。它会增加内存占用，也可能放大下游数据库压力。每次临时改动都要准备回滚路径：

sudo cp /etc/php-fpm.d/www.conf /etc/php-fpm.d/www.conf.bak-20260629
sudo php-fpm -tt
sudo systemctl reload php-fpm

回滚时同样先检查再重载：

sudo cp /etc/php-fpm.d/www.conf.bak-20260629 /etc/php-fpm.d/www.conf
sudo php-fpm -tt
sudo systemctl reload php-fpm

如果回滚后 listen queue 立刻升高，说明业务根因还没有修好；如果回滚后指标稳定，说明临时参数只是应急动作，可以按原容量运行。

告警确认：看哪些指标才算恢复

不要只看“报警消失”。恢复确认至少要覆盖入口、池、日志和下游四层：

• 入口层：接口 P95/P99 回到平时区间，5xx 没有继续增长。
• PHP-FPM 层：listen queue 回到 0，idle processes 恢复稳定。
• 慢日志层：slowlog 不再持续刷同一段业务函数。
• 下游层：数据库 CPU、慢 SQL、连接数没有因扩池继续升高。

可以在重载后每 30 秒采样一次，连续观察 5 分钟：

for i in 1 2 3 4 5 6 7 8 9 10; do
  date "+%H:%M:%S"
  curl -s "http://127.0.0.1/fpm-status" | grep -E "active processes|idle processes|listen queue|max children"
  sleep 30
done

如果入口耗时恢复，但数据库指标明显变差，要立刻停止继续扩池，把重点切回慢 SQL 或后台任务拆分。

复盘项：把慢请求治理变成固定动作

一次慢请求报警结束后，建议沉淀下面几项，下一次值班会快很多：

• 记录触发时间、影响接口、峰值 listen queue、峰值 max children reached。
• 保留 slowlog 中出现次数最多的脚本和函数。
• 写清临时参数改动、重载时间、恢复时间和回滚时间。
• 把根因修复拆成代码、SQL、任务拆分或容量规划任务。
• 给状态页、slowlog 和数据库慢查询建立统一排查面板。

总结一下：PHP-FPM 慢请求报警的关键不是“把参数调大”，而是先判断池是否排队，再用 slowlog 找到请求卡点。池参数负责止血，代码和下游治理负责根因修复。把这些动作写成运行手册，线上排障就不会每次都从猜测开始。