PHP-FPM进程频繁重启大概率是配置主动回收所致，重点排查pm.max_requests过小或slowlog触发的优雅退出，需核对error_log中fpm_children_bury时间戳与slow.log是否吻合。
php-fpm 进程频繁重启，大概率不是“崩了”，而是被配置主动杀掉的——重点查 pm.max_requests 和慢日志触发的优雅退出。
看 slowlog 是否在默默记录超时请求
PHP-FPM 的 slowlog 不仅记“慢”，还会在记录后触发单个 worker 进程退出（尤其当 request_slowlog_timeout 与 request_terminate_timeout 靠得太近时）。这不是错误，是保护机制。
- 确认是否启用了慢日志：
slowlog = /var/log/php-fpm/slow.log且request_slowlog_timeout = 1s（或更小） - 检查日志里是否有密集出现的相同脚本路径，比如反复出现
/var/www/html/api/v1/user.php - 注意时间戳：如果 slowlog 条目和 worker 退出时间高度吻合（查
error_log中[WARNING] fpm_children_bury行），基本可锁定是慢请求导致进程被回收
查 error_log 里是否在刷 “fpm_children_bury” 或 “child exited”
error_log 是判断重启性质的第一现场。别只扫 ERROR 级别，WARNING 和 NOTICE 同样关键。
- 搜
fpm_children_bury：表示 worker 正常退出（非崩溃），常见于pm.max_requests到达上限或 slowlog 触发 - 搜
child exited on signal：带信号编号（如11是 SIGSEGV，6是 SIGABRT），这才是真崩溃，需结合 core dump 分析 - 搜
reloading: executing new binary或received TERM signal：说明是人为 reload/restart，不是自发行为
验证 pm.max_requests 是否设得太小
这个参数控制每个 worker 处理多少请求后自动退出重建。设成 500 在高流量站点可能每分钟都在重启几个进程，看起来就是“频繁”。
立即学习“PHP免费学习笔记（深入）”；
- 查当前值：
grep "pm.max_requests" /etc/php/*/fpm/pool.d/*.conf - 观察实际处理量：用
php-fpm -i | grep "max children"看运行时生效值；再查pm.status_path对应的 status 页面（如curl http://127.0.0.1/fpm-status?full），看requests字段平均值 - 如果平均
requests接近你设的pm.max_requests，且无内存泄漏迹象（free -h看 PHP 相关 RSS 没持续上涨），直接调大到2000或5000即可
别忽略 listen.backlog 和连接队列溢出
当 Nginx 把请求塞不进 PHP-FPM 的 Unix socket 接收队列时，worker 可能因 accept() 失败而异常退出，表现为“突然消失”，继而被 master 拉起新进程，形成假性频繁重启。
- 检查
listen.backlog值，默认128，高并发下极易打满；建议设为1024或更高 - 查系统限制：
cat /proc/sys/net/core/somaxconn，该值必须 ≥listen.backlog，否则会被截断 - 观察 Nginx error log 是否有
connect() to unix:/run/php/php*.sock failed (11: Resource temporarily unavailable)—— 这是明确信号
真正难定位的是 pm.max_requests 和 slowlog 共同作用下的“软退出”：既没报错，又没崩溃，worker 就是安静地、定期地、一个接一个地退出。这时候盯着 error_log 里的时间戳和 slow.log 的匹配关系，比盲目调参管用得多。
