先执行dmesg -t | grep -i "killed process"确认是否oom killer所为，若输出含“out of memory”及php-fpm进程名和signal 9，则坐实；再结合php-fpm日志中“exited on signal 9”及ps与free内存对比综合判断。
不一定，但内存溢出确实是高频诱因之一；更常见的是 pm.max_requests 配置不当或 OPcache 缓存失效引发的连锁泄漏，导致进程被主动 kill，表现为“频繁重启”。
怎么看是不是真被 OOM Killer 杀掉的？
PHP-FPM 进程不是自己退出，而是被系统强制终止时，才会留下明确痕迹：
- 查系统日志：
dmesg -T | grep -i "killed process"—— 若出现killed process php-fpm且附带Out of memory，就是 OOM Killer 下的手 - 看 PHP-FPM 日志（如
/var/log/php8.1-fpm.log）：是否有WARNING: [pool www] child 12345 exited on signal 9 (SIGKILL)—— signal 9 是典型 OOM 标志 - 对比
ps aux --sort=-%mem | head -10和free -h：若 PHP-FPM 进程 RES 列普遍 >80MB 且空闲内存
为什么 pm.max_requests 设太大反而会“重启频繁”？
这个参数本意是让 worker 处理 N 个请求后自动 respawn，以缓解长期运行导致的内存缓慢泄漏。但如果设得过大（比如 pm.max_requests = 102400），worker 就会长时间不重启，泄漏持续累积，最终触发 OOM 被系统强杀——此时你看到的“重启”，其实是被动崩溃，不是配置控制的优雅回收。
- 生产环境推荐值：
pm.max_requests = 200–500（视单请求内存增长幅度而定） - 不要设为 0 或极大值（如 10000+），那等于放弃主动防护
- 改完需
systemctl reload php8.1-fpm（reload 比 restart 更稳妥）
OPcache 失效也会伪装成内存问题
当 OPcache 缓存频繁失效（例如 opcache.validate_timestamps = 1 + 高频文件变更），PHP 会反复 recompile 脚本，每次解析都分配新内存，旧 opcode 却未及时释放，造成内存阶梯式上涨。此时 php-fpm 进程 RES 持续升高，最终被 OOM Killer 清理——看起来像内存溢出，实则是缓存策略失控。
- 检查 OPcache 状态：
php -r "print_r(opcache_get_status());"，重点关注opcache_statistics.memory_usage.used_memory和opcache_statistics.opcache_hit_rate - 生产环境必须关掉校验：
opcache.validate_timestamps = 0，靠手动opcache_reset()或部署时清理 - 若发现
opcache_statistics.opcache_hit_rate ，先查是否模板缓存被误删、Runtime 目录被全量清空等业务层干扰
真正难排查的，往往是 OPcache + pm.max_requests + 动态加载三者叠加：缓存失效 → 解析暴涨 → 内存缓升 → worker 坚持不重启 → 最终爆掉。这时候光看 memory_limit 或加 swap 都没用，得从缓存生命周期和进程回收节奏一起动刀。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
