OOM导致Worker被内核强制kill是间歇性502/504的典型根因，需通过dmesg查“killed process”、比对syslog与Nginx日志时间点、分析进程RSS及smaps内存分布来确认，并配置rlimit_as、pm.max_requests、cgroup等防御措施。
Worker 进程因 OOM（Out of Memory）被系统强制 kill，是引发间歇性 502/504 的典型根因——进程不是崩溃退出，而是被内核 OOM Killer 杀掉，导致 Nginx 瞬间失去可用后端，表现为“突然大量 502”或“部分请求超时变 504”，重启后短暂恢复，几小时后复现。
确认是否为 OOM 导致的 Worker 消失
不能只查服务状态，要找内核级证据：
- 执行
dmesg -T | grep -i "killed process"，若输出中含php-fpm、nginx worker或你的应用进程名，并带时间戳，基本可锁定 OOM - 检查
/var/log/syslog或/var/log/messages，搜索Out of memory: Kill process - 对比故障时间点：Nginx error.log 中首次出现
upstream prematurely closed connection或connect() failed (111: Connection refused)的时间，是否与 dmesg 中 OOM 时间一致 - 查看进程 RSS 内存占用趋势：
ps aux --sort=-%mem | head -10，重点关注 php-fpm worker 或 Java/Python worker 进程是否持续增长至数 GB
定位内存泄漏或峰值爆发点
OOM 是结果，内存异常增长才是真因。需区分是缓慢泄漏，还是突发高峰：
- 对 PHP-FPM：启用
pm.status_path = /status，用curl http://127.0.0.1/status?full查看每个 worker 的内存（memory_usage字段），观察是否存在个别 worker 内存远高于均值（如其他 80MB，某个达 1.2GB） - 对 Java 应用：检查 GC 日志是否频繁 Full GC 且老年代未回收，或使用
jstat -gc观察OU（老年代使用量）持续攀升 - 对 Python：用
psutil或tracemalloc在代码中采样，重点排查未关闭的文件句柄、缓存未清理、大对象循环引用（如 pandas DataFrame 未 del） - 通用手段：用
smaps分析单个 worker 内存分布：cat /proc/，再结合/smaps | awk '/^Size:/ {sum+=$2} END {print sum}' PSS判断共享内存占比
配置层防御与快速缓解
在根因修复前，必须加设安全阀，防止雪崩：
- PHP-FPM 中设置硬性内存限制：
rlimit_as = 512M（限制单个 worker 虚拟内存上限），配合pm.max_requests = 500强制轮换释放累积内存 - Nginx 层增加连接保护：
proxy_next_upstream error timeout http_502 http_504;+max_fails=2 fail_timeout=15s，避免将请求持续打向刚被 kill 的残缺 pool - 系统级防护：调整
/proc/sys/vm/overcommit_memory为2，并设/proc/sys/vm/overcommit_ratio = 80，让内核更严格判断内存分配是否可行 - 紧急降级：临时调低
pm.start_servers和pm.max_children，减少并发 worker 数量，用时间换排查窗口
监控与长期治理建议
OOM 故障不可靠人工巡检，必须固化可观测能力：
- 部署
node_exporter + Prometheus，采集process_resident_memory_bytes{job="php-fpm"}并设告警：单个进程 > 300MB 持续 2 分钟即触发 - 记录每个 worker 启动时间与内存初始值，计算
delta_memory_per_hour，识别缓慢泄漏进程 - 对高频 OOM 服务，启用 cgroup v2 限制整个 php-fpm.service 的内存：
MemoryMax=2G，配合MemorySwapMax=0防止 swap 拖慢响应 - 代码侧审计：禁用全局静态大数组、避免在循环中反复 new 大对象、第三方 SDK 是否存在已知内存 bug（如旧版 Guzzle 在 HTTP/2 下的缓冲区泄漏）
