PHP-FPM 进程池怎么设？并发上限、内存与排队分析
PHP-FPM 进程池决定同时有多少工作进程处理请求，但进程越多并不一定越快。数据库连接、内存和 CPU 可能先达到上限，继续加进程反而让响应变慢。本文以 Ubuntu 24.04 上 PHP 8.3 FPM 为例，其他版本应替换对应配置目录与服务名称。
先看是否真的被进程池限制
记录高峰期请求耗时、错误率、FPM 日志和系统资源，检查是否频繁提示达到工作进程上限。若所有进程都在等待同一数据库锁，增加数量只会让更多请求排队；若 CPU 已长期饱和，也不能靠增加进程制造计算能力。
状态页面能辅助观察活跃进程、空闲进程和队列，但应只允许受控管理来源访问，不能直接公开到网站。先理解采样对应的业务时段，并把慢接口与正常接口分开看，避免平均值掩盖单个功能的问题。
选择模式，再估算上限
FPM 支持固定数量、动态调节和按需创建等模式。动态模式适合需要保留部分空闲进程的场景；按需模式可以减少低负载时的占用，但启动延迟与高峰行为仍需验证。PHP-FPM 配置文档
下面仅示范既有池中的动态参数关系，不是任何配置服务器的推荐值：
pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
估算时先为操作系统、Nginx、数据库和其他服务留出空间，再考虑 PHP 工作进程实际占用。不同页面内存差异很大，不能用启动后空闲进程的大小直接计算安全上限。多个池的上限要合并考虑，不能每个池各自占满整机预算。
运行账号与 FastCGI 入口同样重要
每个池的用户、组和文件权限应与站点需要一致。Nginx 需要连接池的 socket，不等于必须拥有整个网站目录的写权限。修改池账号之前，要核对上传、缓存和日志目录，并避免把其他站点的共享权限一起改掉。
Nginx 的 FastCGI 地址必须与池实际监听位置对应。同机部署可以采用受权限控制的 Unix socket，不能把 FastCGI 端口直接作为公网业务入口。容器环境也应保持在受控内部网络中。Nginx FastCGI 配置说明
新建池并不会自动接管已有站点，代理配置还需要指向新入口。验证前不要删除旧池；先确认它是否仍承载其他站点，避免一次调优影响无关业务。
一次只调整能解释的参数
如果证据表明进程上限造成排队，而且内存、CPU 与数据库仍有余量，可以小幅提高上限并观察。若主要问题是单个慢请求，优先解决查询、外部 API 或应用逻辑，不应只把超时和进程数量一起增大。
对长期运行后内存增长的问题，可以评估进程回收参数，但回收不能代替修复泄漏。频繁创建和销毁进程也有成本。记录每次修改前后的相同业务样本与资源变化，才能判断是改善还是把压力转移到别处。
校验、加载与回退要形成闭环
备份目标池配置后，使用本机对应版本检查，例如 sudo php-fpm8.3 -t。检查通过，再按服务管理方式在合适时段重新加载；服务重启或加载过程中仍需关注现有请求的处理情况。
验证普通页面、上传、后台任务和高峰时的代表性请求，确认 socket 权限、日志和业务都正常。若内存压力、数据库排队或错误率变差，恢复原参数并重新校验、加载。最终记录可解释的容量边界，而不是留下一个没有测试依据的巨大进程数。