确认 PHP-FPM 连接排队需先查 pm.status_path 页面的 listen queue 值：持续大于 0 表明请求在 FPM accept 队列中真实排队；若为 0 但响应慢，则问题在数据库、外部 API 或代码层。
怎么确认是 PHP-FPM 连接排队，而不是其他环节卡住
别急着改配置，先看 pm.status_path 页面返回的 listen queue 值——它代表当前有多少请求在 FPM 的 accept 队列里等着被 worker 拿走。只要这个数持续大于 0，就说明请求真正在排队；如果它一直是 0，但接口还是慢，那问题大概率出在数据库、外部 API 或 PHP 代码本身。
同时检查 Nginx error log，出现 connect() failed (11: Resource temporarily unavailable) 就是 backlog 队列溢出的铁证；而 max_children_reached 在 status 页面里不断上涨，说明 pm.max_children 确实不够用了。
-
listen queue> 0 且持续增长 → FPM 进程池处理不过来 -
max_children_reached非零且递增 → 当前进程上限已成瓶颈 - Nginx 报
Resource temporarily unavailable→ 内核层面的net.core.somaxconn或 FPM 的listen.backlog太小
pm.max_children 设多少才合理，不是越大越好
盲目调大 pm.max_children 很容易触发 OOM：每个 PHP-FPM worker 在实际业务中常驻内存约 20–40MB（取决于扩展加载和脚本复杂度），设成 200 就可能吃掉 6GB+ 内存。一旦系统开始 swap，性能反而断崖下跌。
更稳妥的做法是按服务器可用内存倒推：
立即学习“PHP免费学习笔记（深入）”；
- 用
free -m看剩余可用内存（排除 cache/buffer） - 预留 2GB 给系统和其他服务（MySQL、Redis 等）
- 单个 worker 估算内存：用
ps aux --sort=-%mem | grep 'php-fpm' | head -5观察 RSS 峰值 - 计算上限：
(可用内存 - 2048) / 单 worker RSS，向下取整
例如：8GB 机器，可用内存约 5.5GB，worker 平均占 32MB → pm.max_children ≈ 109，建议设为 100 并留点余量。
pm = dynamic 还是 static？为什么 dynamic 容易“假空闲”
默认 pm = dynamic 看似智能，但它的 pm.min_spare_servers 和 pm.max_spare_servers 如果设得太保守（比如都设成 5），会导致高峰来临时来不及 fork 新进程——旧 worker 还没释放完，新请求就已在队列里堆积。
更关键的是：pm.max_requests 设太小（如默认 0 或 500）会让 worker 频繁重启，既浪费 fork 开销，又导致连接池（如 PDO 持久连接）无法复用。
- 高并发稳定服务建议用
pm = static，直接固定 worker 数（等于你算出的pm.max_children） - 若必须用
dynamic，把pm.start_servers设为min_spare_servers和max_spare_servers的中间值，pm.max_requests改为2000以上 - 无论哪种模式，都要关掉
pm.process_idle_timeout（默认 10s），避免空闲 worker 被误杀
除了 FPM 配置，还有三个地方必须同步调
FPM 是瓶颈，但它的上游和下游不匹配，照样白调。这三处漏掉一个，pm.max_children 再大也没用：
-
listen.backlog必须 ≥pm.max_children（Linux 默认是 511，经常不够） -
net.core.somaxconn（内核参数）要 ≥listen.backlog，否则内核会悄悄截断 - MySQL 的
max_connections至少要比pm.max_children高 30%～50%，否则所有 worker 一并发连库就阻塞
例如你设了 pm.max_children = 100，那就得确保：listen.backlog = 1024，net.core.somaxconn = 1024，MySQL max_connections ≥ 150。这些值不一致，排队就会发生在不同层级，排查起来极难定位。
真正卡住的往往不是代码，而是这几行配置之间的错位。调参不是填数字，是让整个链路的容量对齐。
