PHP-FPM 慢请求为什么拖垮整池：pm.max_children、慢日志与分层限流

线上 PHP 接口突然从 200ms 变成几秒，Nginx 的 upstream 超时只是表象，真正的瓶颈往往是 PHP-FPM 的 worker 已经被慢请求占满。此时直接把 pm.max_children 调大，可能让内存先出问题，甚至把数据库连接数一起推过上限。

先看清 PHP-FPM 池是慢，还是已经没有空闲 worker

先打开对应 pool 的状态页，关注 active processes、idle processes、总进程数和 max active processes。连续多个采样周期里 idle processes 为 0，同时 max active processes 等于 pm.max_children，才说明请求正在排队等待 worker。

如果 active processes 不高但响应仍慢，问题可能在 MySQL、Redis、外部 HTTP 或磁盘，不要把 FPM 当成万能性能开关。这里先别急着改配置，慢日志里的 URI、执行时长和调用栈更有价值。

用三个预算计算 pm.max_children，而不是凭经验加进程

进程池上限至少要同时满足内存预算和下游容量预算。可以先用一台稳定实例的 RSS 做保守估计：

可分给 FPM 的内存 = 主机可用内存 - 系统余量 - 数据库/缓存预留
pm.max_children = floor(可分给 FPM 的内存 / 单个 worker 的峰值 RSS)

单个 worker 不要取平均值。选择高峰期最大的几个采样值，再留出升级和异常请求的余量。比如某接口会临时导出报表，它的峰值远高于普通列表页，就应该单独拆到另一个 pool，而不是让所有站点共同承担。

慢日志要记录到能推动修复的粒度

在 pool 配置中设置慢请求阈值和日志路径，阈值不要一上来就设成几秒。可以先以接口的正常 P95 为参考，再用少量余量捕捉异常。日志必须能对应到 URI、请求方法和执行入口，避免只得到一条“某个 worker 很慢”的无用信息。

request_slowlog_timeout = 1s
slowlog = /var/log/php-fpm/www-slow.log
request_terminate_timeout = 30s

request_terminate_timeout 是最后一道止损线，不是修复慢 SQL 的工具。它过短会截断正常的大文件处理，过长又会让 worker 长时间不归还。配置修改后先 reload 一个实例，观察慢日志数量、5xx、内存和数据库连接，再逐步扩大范围。

把削峰和隔离放到 FPM 进程池之外

当突发流量来自同一个接口时，入口层应先限制排队长度和请求速率；FPM 只承接已经准入的工作。对报表导出、图片处理、批量回调这类长请求，可以拆到独立 pool，甚至改成队列任务，让普通登录和下单请求不再与它们抢 worker。

分层之后要保留清晰的失败表现：入口限流返回可识别的 429，FPM 超时记录请求标识，异步任务进入可重试队列。不要把所有异常都伪装成 200，否则监控会失去方向。

一次安全上线的顺序：采样、灰度、回切

1. 先记录 10 到 15 分钟的活跃/空闲进程、请求时长、RSS、swap、5xx 和下游连接数。
2. 只调整一个变量，例如先改 pm.max_children，保留旧配置并在单实例 reload。
3. 用固定压测流量或真实低比例流量验证 P95、P99、内存峰值和慢日志变化。
4. 如果内存抖升、数据库连接打满或超时增加，立即回切配置，不要用继续加进程掩盖症状。

常见问题：为什么进程越多，接口反而越慢

pm.max_children 越大吞吐就一定越高吗？

不是。worker 超过内存或下游连接预算后，会引发 swap、上下文切换或数据库排队，吞吐和尾延迟都会变差。

FPM 状态页显示没有空闲进程，就一定是 PHP 代码慢吗？

不一定。worker 可能在等待 MySQL、Redis 或外部服务。要把状态采样和慢日志、下游耗时放在一起看。

什么时候应该拆出独立 pool？

当一类请求的执行时长、内存峰值或失败策略明显不同，并且它会影响登录、下单等核心请求时，就值得单独隔离。

把验证结果留在发布清单里

这类调整的验收不应只看“页面能打开”。至少保留配置版本、单进程峰值 RSS、FPM active/idle、P95/P99、5xx、慢日志样本和下游连接峰值。下次池再次接近上限时，值班人员可以直接判断是流量突增、某个接口变慢，还是下游容量不足。