PHP-FPM 高峰排队时怎样估算进程上限

PHP-FPM 高峰排队时，pm.max_children 不应该按“CPU 核数乘一个倍数”直接拍板。它首先是并发请求上限，同时还会把每个 PHP 子进程占用的内存、数据库连接和 CPU 争用放大。比较稳妥的做法是：先算出内存上限，再分别算 CPU 和下游连接上限，最后取最小值，再用 status 页面观察排队是否真的改善。

官方地址：https://www.php.net/manual/en/install.fpm.configuration.php

下面的数字只是演示估算方法，不是某台机器的实测结果。本文把 FPM 子进程和下游服务当作需要保护的资产，把“请求堆在 listen queue 中”当作风险信号，重点回答一个问题：怎样设一个能解释、能回滚的起始值。

先确定真正要保护的资源

一次 PHP 请求可能同时占用一个 FPM 子进程、一段进程 RSS、一个或多个数据库连接，以及 CPU 时间。把 pm.max_children 继续调大，只会让更多请求进入执行态；如果数据库已经没有连接槽位，或者每个子进程都很重，队列可能从 FPM 移到别处，整机还会开始交换。

因此先列出四个约束：

• 内存：留出操作系统、Web 服务器、数据库客户端、缓存和安全余量后的内存，才能给 FPM。
• CPU：高并发不是免费吞吐。CPU 密集型脚本的并发上限通常比 I/O 等待型脚本更低。
• 下游连接：如果每个请求都要占用数据库连接，FPM 子进程数不能超过连接池和数据库剩余预算。
• 排队可接受度：短时队列可以被吸收，持续增长的队列说明当前容量或请求耗时有问题。

用进程内存估算第一道上限

先观察业务高峰时 FPM 子进程的高位 RSS，而不是拿一个刚启动进程的空闲内存做除数。可以用一段时间内的高位样本，或者从进程监控中取接近 P95 的值。估算式如下：

# 可分配给 FPM 的预算 = 总内存 - 系统与旁路服务 - 安全余量
# 内存上限取整，避免把小数进程当成可用容量
内存上限 = floor(FPM 可用内存 / 单个子进程高位 RSS)

例如，一台 8 GB 主机预留 2 GB 给系统和其他服务，再留 512 MB 安全余量，得到约 5.5 GB 的 FPM 预算。如果单个子进程的高位 RSS 约为 180 MB：

# 这里的数字是示例，实际应替换成业务高峰采样值
FPM 预算 = 8192 - 2048 - 512 = 5632 MB
内存上限 = floor(5632 / 180) = 31

这个 31 不是最终配置，而是第一道不能轻易越过的边界。若 PHP 扩展、图片处理或某类慢请求会使 RSS 明显变大，应使用更高位的样本；否则平时看起来正常，高峰时仍可能被内存反噬。

把 CPU 与下游连接数加入取小值

内存上限只说明“装得下多少个进程”，还不说明这些进程能否有效工作。可以为 CPU 和连接数各算一个保守的候选值：

# CPU 候选值只用于建立起始边界，不替代压测
CPU 上限 = floor(可分配 CPU 容量 / 单请求平均 CPU 消耗)

# 连接预算要扣除管理后台、定时任务和其他 PHP 池占用
连接上限 = floor(数据库可用连接数 / 每个请求平均连接占用)

# 最终起始值取所有资源上限中的最小值
pm.max_children = min(内存上限, CPU 上限, 连接上限)

继续用示例说明：如果 CPU 预算折算后得到 24，数据库还允许这个池使用 20 个并发连接，那么最终起始值应是 min(31, 24, 20) = 20，而不是把 31 直接写进配置。若应用使用连接池或一个请求会串行访问多个下游，连接预算要按实际占用方式修正。

这个取最小值的动作是保护边界：它牺牲一部分理论并发，换来更可控的内存和下游压力。对 CPU 等待少、外部 I/O 多的应用，CPU 上限可能不是最小值；对复杂报表和图片处理请求，CPU 或内存往往会先成为瓶颈。

用 FPM 状态页观察排队风险

PHP-FPM 的 status 页面可以告诉你当前池里有多少活跃、空闲进程，以及请求是否在等待空闲进程。PHP 官方文档列出的关键字段包括 listen queue、max listen queue、active processes、idle processes、max active processes 和 max children reached。

建议把这些字段放在同一个时间窗口看：

• listen queue 持续大于 0，说明当前有请求等空闲进程；如果同时 active 接近上限，FPM 并发边界很可能偏小。
• max children reached 表示历史上曾经碰到过进程上限，但它本身不能证明调大后一定更快。
• active 很低但请求仍慢，优先查数据库、外部 HTTP、锁或单请求耗时，不要只增加进程数。
• idle 长期很多而 queue 没有积压，说明当前值可能偏宽松，但仍要结合内存余量再缩小。

; 只给内部监控路径使用，避免把资源信息暴露给公网
pm.status_path = /fpm-status

; dynamic 让空闲进程和启动进程数在边界内变化
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8

status 页面应该限制为内网或已知监控来源。它会暴露池的资源信息，不能把它当成普通业务页面公开。

用受控配置和回滚方式落地

把估算值落地时，先保存原配置，再一次只改一个变量。建议顺序是：记录当前 pm.max_children 和资源曲线；设置一个略低于多项上限最小值的起始值；在同一高峰窗口观察 queue、RSS、CPU、数据库连接和错误率；确认没有持续积压后，再小步增加。

# 先备份当前池配置，保留可回滚副本
cp /etc/php/8.3/fpm/pool.d/www.conf /etc/php/8.3/fpm/pool.d/www.conf.bak

# 修改后先检查配置语法，再平滑重载；路径按发行版实际位置调整
php-fpm8.3 -t
sudo systemctl reload php8.3-fpm

如果内存开始逼近预算、数据库连接经常打满，或者 queue 下降但整体延迟反而上升，应先把值调小；如果 queue 只在瞬时尖峰出现、资源仍有充足余量，再考虑小步上调。回滚时恢复备份并重新检查配置，不要连续多次改动让比较失去基线。

结论：把进程上限当成资源预算

一个可解释的起始公式是：

# 先分别计算每个资源的安全上限，再取最小值
pm.max_children = min(
    floor(FPM 可用内存 / 子进程高位 RSS),
    CPU 并发预算,
    数据库连接预算
)

然后用 status 页判断“排队是否还在、进程是否触顶、下游是否被压满”。pm.max_children 的目标不是让 FPM 永远没有队列，而是在可接受延迟内消化流量，同时把内存、CPU 和下游连接留在可恢复范围。

常见追问

只看服务器内存够不够吗？

不够。内存只能给出一个硬边界，CPU 和数据库连接可能更早成为瓶颈；最终仍应取多个候选上限中的最小值。

看到 max children reached 就应该调大吗？

不应该直接调大。先看 queue 是否持续、active 是否饱和，以及 RSS、CPU 和下游连接是否还有余量。

动态模式下 pm.max_children 还重要吗？

重要。动态模式只是让进程数在其他参数配合下变化，pm.max_children 仍是最大子进程数。