直接查看 PHP-FPM 实际运行的工作进程数并与 pm.max_children 比对可确认是否耗尽；可通过 ps 命令、systemctl status 或 FPM 状态页验证，再结合 Nginx 错误日志与内存使用情况（如 OOM killer 记录）综合判断真实瓶颈。
直接看 PHP-FPM 实际运行的子进程数，再和配置上限比对，就能确认是否耗尽。这不是猜的，是可验证的事实。
查当前活跃的 PHP-FPM 进程数量
执行命令查看真实运行中的工作进程数（不含主进程）：
- ps -eo comm,args | grep 'php-fpm:' | grep -v 'grep' | wc -l —— 最简洁可靠的方式，只统计工作进程
- 或用 systemctl status php8.1-fpm | grep "active.*process" 快速看状态摘要
- 如果启用了 FPM 状态页（
pm.status_path = /status），访问http://yoursite/status?full，重点看active processes和idle processes两项：若idle长期为 0，且active接近或等于max_children，就是耗尽信号
核对 PHP-FPM 的最大子进程限制
打开对应版本的 pool 配置文件，例如：
- /etc/php/8.1/fpm/pool.d/www.conf
- 找到
pm = dynamic或pm = static行，再看关键参数：
•pm.max_children（总上限）
•pm.start_servers、pm.min_spare_servers（冷启动缓冲） - 注意：如果设的是
pm = static，那pm.max_children就是恒定进程数，没有伸缩空间，更容易打满
结合 Nginx 错误日志交叉验证
打开 /var/log/nginx/error.log，搜索这些关键词：
立即学习“PHP免费学习笔记（深入）”；
- "no live upstreams" —— 表明所有 PHP-FPM 进程都不可用（可能全忙或已僵死）
- "upstream sent no valid HTTP/1.0 header" —— 进程卡在输出前崩溃，常伴随耗尽后的新请求失败
- "recv() failed (104: Connection reset by peer)" —— 某些进程被强制回收，新请求连不上空闲进程
观察内存是否成为隐性瓶颈
进程数没超限，但照样 502？可能是内存先撑不住了：
- 用 free -h 和 top 查看可用内存是否持续低于 200MB
- 每个 PHP-FPM 进程平均占 60–100MB（取决于扩展和脚本），若
pm.max_children = 30，按 80MB 算就需 2.4GB 内存；服务器只有 2GB 可用，实际撑不到 30 个进程就会 OOM 被 kill - 检查系统日志：dmesg -T | grep -i "killed process"，若有
php-fpm被 OOM killer 干掉，就是内存导致的假性“耗尽”
