PHP PHP-FPM worker 并发 怎样处理

我处理 PHP-FPM 并发时，最先改掉的习惯是“看到请求排队就把 worker 调大”。PHP-FPM 的并发上限首先受 pm.max_children 控制，但每个 worker 都会占用内存、连接和文件描述符；数量过大时，排队可能变成交换、数据库连接耗尽或整体抖动。

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

实际处理顺序应该是：先确认当前池的进程模型，再用 FPM 状态页判断是否真的触顶，随后结合慢日志和下游资源决定是否调整 pm.max_children。低频站点优先考虑 ondemand，持续流量通常从 dynamic 开始；pm.max_requests 只负责 worker 的生命周期回收，不会直接提高并发。

先把 PHP-FPM worker 并发看成容量关系

PHP-FPM 的 master 进程负责管理 worker，worker 一次处理一个 FastCGI 请求。官方配置手册把 pm.max_children 定义为同时处理请求的上限：static 模式下它是固定子进程数，dynamic 和 ondemand 下它是可创建的最大子进程数。它不是“CPU 核数乘以某个固定倍数”，因为请求可能同时等待数据库、外部 HTTP 或文件系统。

因此，调整前先回答三个问题：

• 当前 worker 是否经常达到 pm.max_children；
• 达到上限时，请求是 CPU 忙、PHP 代码慢，还是下游资源在等待；
• 把 worker 增加后，内存和数据库连接是否仍有余量。

按请求到达模式选择 pm

static 直接保持固定数量的 worker，适合流量稳定且内存预算明确的池；它的优点是容量容易估算，代价是低峰期也会保留这些进程。

dynamic 根据 pm.start_servers、pm.min_spare_servers、pm.max_spare_servers 和 pm.max_children 调节常驻规模，通常更适合有明显高低峰但希望保留一部分热进程的站点。

ondemand 在请求到达时创建 worker，空闲达到 pm.process_idle_timeout 后回收，适合后台管理、低频接口或多个很少同时访问的池。它可能带来首次请求的进程创建成本，所以不能只看“空闲时省内存”。

; 这是 PHP-FPM pool 的示意配置，数值应按本机资源预算调整
[www]
pm = dynamic
pm.max_children = 24
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 12
; 低频池可改为 ondemand，并设置空闲 worker 的回收时间
; pm = ondemand
; pm.process_idle_timeout = 10s

配置文件改动后要按发行版实际服务名执行语法检查、平滑重载并观察变化；不要把“配置已经写入文件”当成“新 worker 数已经生效”。

用状态页和慢日志判断是否真的触顶

PHP-FPM 状态页提供活动进程、空闲进程和 max children reached 等信息。这个字段表示曾经达到过进程上限，但它本身不能说明应该增加多少 worker；还要结合请求耗时和宿主机内存看。

如果状态页显示上限被触发，同时慢日志里有长时间占用 worker 的请求，应先定位慢查询、外部 HTTP 或锁等待。单纯加大 worker 可能让更多请求一起卡在同一个下游。若 PHP 请求本身很快，但高峰期偶发触顶，可以小步增加上限，再观察内存、数据库连接和排队是否同步改善。

; 开启慢日志和慢请求栈深度，用于定位长时间占用 worker 的请求
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_trace_depth = 20
; 状态页路径要限制在内网或已知客户端，不能公开暴露

用 pm.max_requests 管理 worker 生命周期

pm.max_requests 表示每个子进程处理多少请求后重新生成，官方文档说明它可以用于缓解第三方库造成的内存泄漏；设为 0 表示不限制。它是回收策略，不是并发扩容开关。

; 每个 worker 处理一段请求后重建，避免长期累积的进程内存持续上涨
pm.max_requests = 500

这个值不应照抄。重建过于频繁会增加创建进程和预热成本；完全不回收又可能让偶发的进程内存增长长期保留。比较稳妥的做法是先记录 worker 常驻内存走势，再从较大的值开始观察重建频率和延迟变化。

最后按资源预算小步调整

可以把一次调整拆成下面这张表，先从最小变化开始：

我通常会把单 worker 的稳定内存占用乘以目标 worker 数，再给系统、Web 服务器、数据库客户端和突发留出余量；这是容量估算，不是 PHP 官方固定公式。调整后只改变一个主要变量，并记录状态页、慢日志和主机资源的变化，下一轮才有可比较的依据。

常见问题

pm.max_children 越大并发就越高吗？它提高的是 FPM 同时处理请求的进程上限，但最终吞吐还受 CPU、内存、数据库和外部服务限制。

pm.max_requests 能解决请求排队吗？不能。它控制 worker 处理请求后的重建时机，排队仍应从进程上限和单请求耗时入手。

状态页显示 max children reached 就一定要扩容吗？不一定。先确认触顶时是否存在慢请求或下游瓶颈，资源有余量时才适合小步调整。