php-fpm子进程被杀致502主因是pm.max_children设置过低或oom，需结合内存与秒级并发调优；务必开启slowlog定位慢脚本；关闭宝塔自动重启以暴露真实问题；opcache须合理配置避免反向增压。
PHP-FPM子进程被杀导致502：看pm.max_children是否真够用
宝塔面板默认的pm = dynamic配法在高并发下经常失灵，不是“不够用”，而是pm.max_children设得太保守，同时pm.start_servers又太低，请求一涌进来，新进程起不来，旧进程还在忙，php-fpm直接拒绝新连接，Nginx就报502。
实操建议：
- 先查当前实际峰值子进程数：
ps aux | grep 'php-fpm:' | grep -v grep | wc -l，对比配置里的pm.max_children - 别只看平均QPS，要盯住秒级突增——比如抢购、定时任务触发、爬虫扫首页，这些会让
pm.max_children瞬间打满 - 如果服务器有4GB内存，每个PHP子进程常驻约30–50MB（视扩展而定），
pm.max_children超过80就容易OOM；此时宁可调低pm.max_spare_servers，也要留出缓冲余量 - 改完记得重载：
sudo systemctl reload php-fpm（注意不是restart，避免中断已有请求）
慢日志没开，根本不知道哪个脚本在拖垮FPM
不看slowlog，你永远以为是并发高，其实是某个接口执行了30秒MySQL查询，卡住一个worker，连带整个池子雪崩。
实操建议：
- 确认
php-fpm.d/www.conf里开了slowlog = /www/wwwlogs/php_slow.log和request_slowlog_timeout = 5s - 别信宝塔界面里“已启用慢日志”的勾选框——它只改
slowlog路径，不保证request_slowlog_timeout生效，必须手动检查 - 日志里出现
[pool www] child 12345, script '/www/wwwroot/api/v1/user.php' (request: "GET /api/v1/user.php")这种行，就立刻去查那个脚本的SQL或curl调用 - 临时加个
request_terminate_timeout = 30s防死锁，但只是兜底，不能替代优化
宝塔自动重启PHP-FPM掩盖了真实问题
面板默认开启“服务异常自动重启”，看着服务“恢复”了，其实是把正在处理的请求全干掉，用户看到的是504或空白页，而你日志里只剩一句WARNING: [pool www] child 6789 exited on signal 9 (SIGKILL)——这基本等于内存被系统OOM Killer清掉了。
实操建议：
- 进宝塔 → 软件商店 → PHP → 设置 → 配置修改 → 把“服务异常自动重启”关掉
- 改完立刻去
/var/log/messages或dmesg -T | grep -i "killed process"确认是不是OOM - 如果是OOM，优先压测单个PHP脚本内存占用（
memory_get_peak_usage(true)），而不是盲目加pm.max_children - 宝塔的“性能调整”一键优化脚本会强行覆盖你的
www.conf，改完配置后记得chattr +i /www/server/php/82/etc/php-fpm.d/www.conf锁文件（升级PHP版本前再解锁）
OPcache未启用或配置过激，反而加重FPM压力
没开OPcache，每个请求都要重编译PHP文件；开得过激（比如opcache.validate_timestamps=0却忘了定期reload），又会导致代码更新不生效、调试困难，甚至因共享内存碎片引发worker卡死。
实操建议：
- 确认
opcache.enable=1且opcache.enable_cli=0（CLI不用开） - 生产环境设
opcache.validate_timestamps=0，但必须配合部署脚本执行kill -USR2 $(cat /www/server/php/82/var/run/php-fpm.pid)来热刷新 -
opcache.memory_consumption别设太高——128MB对多数站点已够用，设512MB可能让FPM启动变慢，还挤占可用内存 - 用
opcache_get_status()查命中率，低于95%就要查是否opcache.revalidate_freq设得太小，频繁校验文件时间戳
pm参数。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
