PHP-FPM出现“server reached pm.max_children”怎么办？进程池、慢请求与内存占用排查教程

PHP-FPM 日志出现 server reached pm.max_children setting，说明当前进程池允许同时工作的子进程已经全部被占用，新请求只能等待。网站此时可能打开变慢，也可能伴随 Nginx 502、503、接口超时或后台卡顿。

这条日志不等于“把 pm.max_children 调大就能解决”。如果请求本身很慢、数据库阻塞、外部接口迟迟不返回，盲目增加进程数只会让更多 PHP 进程同时占用内存，严重时会触发系统 OOM。排查时要同时看进程池队列、单个进程的内存、慢请求来源和服务器剩余资源。

先确认是哪一个 PHP-FPM 进程池达到上限

一台服务器可能同时安装多个 PHP 版本，也可能为不同网站配置多个 pool。先从 PHP-FPM 日志中确认 pool 名称、发生时间和告警频率。

journalctl -u php8.3-fpm --since "30 minutes ago" --no-pager

使用独立日志文件的环境可以搜索相关提示：

grep -R "reached pm.max_children" /var/log/php* /var/log/php-fpm* 2>/dev/null

服务名和日志路径会随发行版、PHP 版本及安装方式变化。常见服务名包括 php-fpm、php8.3-fpm、php8.4-fpm。不要在没有确认版本的情况下直接修改第一个找到的配置文件。

可以用配置测试命令查看当前实际加载的参数：

php-fpm -tt 2>&1 | grep -E 'pm =|pm.max_children|pm.start_servers|pm.min_spare_servers|pm.max_spare_servers|pm.max_requests|slowlog|request_slowlog_timeout'

如果系统没有 php-fpm 命令，按实际版本尝试 php-fpm8.3 -tt 或 php-fpm8.4 -tt。

判断是瞬时突发，还是长期容量不足

偶尔出现一次告警，可能只是爬虫、批量任务或短时流量突发。告警持续出现，同时网站响应变慢，才说明当前容量或请求处理时间存在稳定问题。

PHP-FPM 状态页比单看日志更直观。启用 pm.status_path 后，可重点检查：

• listen queue：正在排队、尚未交给 worker 的连接数；
• active processes 与 idle processes：忙碌和空闲进程数量；
• max children reached：进程数触顶的累计次数；
• slow requests：达到慢请求阈值的累计数量。

状态页包含服务运行信息，不应直接暴露到公网。可以限制为本机或管理网访问，也可以为状态页配置独立监听，避免主进程池繁忙时连状态页都打不开。

估算 PHP-FPM 实际占用了多少内存

pm.max_children 的上限受内存约束。先观察 PHP-FPM 进程数量和 RSS：

ps --no-headers -o rss,cmd -C php-fpm | awk '{sum+=$1;n++} END {if(n) printf "processes=%d avg_rss=%.1f MB total_rss=%.1f MB\n",n,sum/n/1024,sum/1024}'

不同系统的进程名称可能带版本号，上述结果也可能把 master 进程计入，因此只能作为快速估算。更稳妥的做法是在正常负载和高峰期分别采样，关注业务 worker 的较高内存占用，而不是只看刚启动时的平均值。

可分配给 PHP-FPM 的内存 ÷ 单个 worker 的高峰内存 ≈ 可承受的进程数

“可分配内存”必须先扣除操作系统、Nginx、数据库、Redis、监控和文件缓存需要的空间。数据库与 PHP 部署在同一台小内存服务器上时，给 PHP-FPM 留满全部空闲内存风险很高。

用 slowlog 找出占住 worker 的请求

进程池触顶经常不是并发量突然变大，而是部分请求占用 worker 的时间过长。可以在对应 pool 配置中启用慢请求日志：

slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 5s

配置生效后，PHP-FPM 会把超过阈值的请求调用栈写入 slowlog。阈值应结合站点正常响应时间设置，不能机械照抄 5 秒。电商导出、备份、图片处理等长任务应尽量转入队列或命令行任务，不要长期占用处理网页请求的进程池。

排查 slowlog 时常见的源头包括：

1. SQL 查询缺少索引、锁等待或数据库连接变慢；
2. 外部 API、支付接口、DNS 或对象存储响应超时；
3. WordPress 插件执行耗时，WP-Cron 在访问请求中集中运行；
4. 网络文件系统、磁盘 I/O 或日志写入变慢；
5. PHP 代码死循环、锁竞争，或单次任务处理的数据量过大。

同时查看 Nginx access log 的请求耗时、数据库慢查询日志和系统负载，才能把“哪个请求慢”与“为什么慢”对应起来。

安全调整进程池参数

确认服务器仍有足够内存，并且业务确实需要更高并发后，再调整对应 pool。下面只是一组结构示例，不是所有服务器都适用的推荐值：

pm = dynamic
pm.max_children = 24
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_requests = 500

在 dynamic 模式下，pm.max_children 是同时处理请求的子进程上限；其他参数控制启动及空闲进程数量。pm.max_requests 可缓解第三方扩展长期运行造成的内存膨胀，但不能修复慢 SQL、外部接口超时或容量不足。

修改前先备份 pool 配置：

cp /etc/php/8.3/fpm/pool.d/www.conf /etc/php/8.3/fpm/pool.d/www.conf.bak-$(date +%F-%H%M)

路径按实际环境修改。完成后检查语法并平滑重载：

php-fpm8.3 -t
systemctl reload php8.3-fpm

如果当前服务不支持 reload，应安排在低峰期重启，并提前确认回滚配置。不要在业务高峰同时大幅修改进程数、超时和数据库参数。

不要用 Nginx 超时参数掩盖进程池问题

fastcgi_read_timeout 控制 Nginx 等待 FastCGI 响应数据的时间。单纯把它调大，只会让请求更晚报错，不会增加 PHP-FPM worker，也不会缩短慢请求。

request_terminate_timeout 可以终止运行过久的 PHP 请求，但阈值过短可能截断正常导入、备份、报表和支付回调。应先找出请求为何变慢，再为确实需要保护的场景设置超时边界。

修改后怎样确认问题已经解决

重载服务后至少观察一个真实高峰周期，检查以下项目：

1. PHP-FPM 配置测试通过，服务状态正常；
2. listen queue 是否回落，空闲进程是否长期为 0；
3. max children reached 的增速是否停止；
4. Nginx 502、503 和 upstream timeout 是否减少；
5. PHP-FPM 总内存是否在可控范围，系统是否发生 swap 抖动或 OOM；
6. slowlog 中的同类慢请求是否已通过代码、SQL 或架构调整解决。

如果增加 pm.max_children 后队列消失，但内存逼近上限，说明只是把瓶颈从并发槽位转移到了内存。此时应继续优化慢请求、拆分数据库或后台任务，必要时升级实例。

长期预防

为 PHP-FPM 状态指标设置监控，至少记录 active、idle、listen queue、max children reached 和 slow requests。WordPress 定时任务、数据导出、图片处理和队列消费者尽量与前台 Web 请求隔离，避免一次后台任务耗尽整个进程池。

遇到 server reached pm.max_children 时，先确定请求为什么占住 worker，再判断是否真的需要更多 worker。这样才能同时处理响应速度和内存风险。

参考资料

• [PHP：FastCGI 进程管理器配置](https://www.php.net/manual/zh/install.fpm.configuration.php)
• [PHP：FPM 状态页](https://www.php.net/manual/zh/fpm.status.php)
• [PHP：FastCGI 进程管理器安装与配置](https://www.php.net/manual/zh/install.fpm.php)
• [Nginx：ngx_http_fastcgi_module](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html)

资料核验日期：2026年9月4日。不同发行版、PHP 版本和安装方式的服务名、配置路径及默认值可能不同，操作前请以当前服务器的实际配置和对应版本官方文档为准。