子进程频繁退出大概率是pm.max_requests设得太小；查error_log中fpm_children_bury或“child exited with code 0”日志，结合pm.status_path的requests值是否稳定接近配置值即可确认。
子进程频繁退出，大概率是 pm.max_requests 设得太小，而不是内存泄漏或崩溃。
怎么确认是 pm.max_requests 导致的退出
查 error_log（比如 /var/log/php-fpm/www-error.log）里有没有高频出现这两类日志：
-
fpm_children_bury—— 表示 worker 主动退出，不是 crash -
child exited with code 0—— 退出码为 0，说明是正常寿终正寝
再对比这些日志的时间戳和你配置的 pm.max_requests 值：如果每个进程处理请求数（从 pm.status_path 的 requests 字段看）稳定在比如 490–510 之间，而你设的是 pm.max_requests = 500，基本就是它了。
别只扫 ERROR 级别日志；WARNING 和 NOTICE 里才有 fpm_children_bury 这种关键线索。
pm.max_requests 该设多少才合理
这个值不是拍脑袋定的，得看实际负载和内存表现：
- 先查当前生效值：
php-fpm -i | grep "max requests"或直接读配置文件：grep "pm.max_requests" /etc/php/*/fpm/pool.d/*.conf - 再看真实请求量：
curl "http://127.0.0.1/fpm-status?full" 2>/dev/null | grep "^requests:"，观察平均值是否长期接近你设的上限 - 同时用
free -h和ps aux --sort=-%mem | grep php-fpm看 RSS 是否随时间持续上涨 —— 如果不涨，就不是泄漏，只是“到点退休”
无明显泄漏时，pm.max_requests = 2000 是较稳的起点；高并发站点可设到 5000；设成 0 表示永不重启，但得确保代码和扩展没内存问题。
容易被忽略的关联参数
pm.max_requests 不是孤立的，它和下面两个参数共同影响退出节奏：
-
pm.process_idle_timeout：空闲进程存活时长。如果设得太短（比如10s），哪怕没到max_requests，也会因空闲超时被杀 —— 日志里会看到idle timeout字样 -
pm.max_children：如果这个值太小，又启用了dynamic模式，max_requests触发退出后，新进程可能还没来得及拉起，就导致连接队列积压甚至 502
另外，listen.backlog 默认只有 128，高并发下 socket 接收队列打满，worker 在 accept() 阶段失败，也可能被 master 强制回收 —— 看日志是否有 failed to accept connection 类报错。
真正麻烦的不是调大 pm.max_requests，而是调大之后发现 RSS 开始缓慢爬升 —— 那就得切到内存分析模式，而不是继续调参。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
