确认OOM Killer杀死进程需先执行dmesg -T | grep -i "killed process"，若输出含时间戳、PID、进程名及vmrss值则坐实；再查/proc/<pid>/status中VmRSS和smaps中USS定位真实内存占用，结合语言特性（如Java用jmap、Python用tracemalloc）分析泄漏源头，并可通过oom_score_adj调低关键进程被杀优先级。
直接看 dmesg 输出，确认是不是 OOM Killer 干的；不是就不用往下看了。
第一步：确认是否真被 OOM 杀死
执行：
dmesg -T | grep -i "killed process"
如果输出类似：
[Wed Sep 20 02:14:22 2026] Out of memory: Killed process 12345 (java) score 892, adj 0, vmsize 4215684kB, vmrss 3125608kB
说明确实是 OOM Killer 下的手。时间戳、进程名、PID、oom_score 和实际物理内存占用（vmrss）都列得清清楚楚。
注意：
• 不要只查 /var/log/messages 或 journalctl，dmesg 的内核日志最原始、最全，重启后部分会被刷掉，所以必须第一时间取；
• 如果没搜到，可能是还没触发 OOM，或是被其他信号（如 SIGKILL）终止，别在 OOM 路上白费功夫。
第二步：查进程真实内存占用，区分“虚”和“实”
OOM 杀的是 RSS 高的进程，但 RSS 高 ≠ 真泄漏。很多进程虚拟内存（VIRT）很大，但驻留物理内存（RSS）并不高——比如 mmap 了大文件但没读，或用了大量共享库。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
重点看这两个值：
• VmRSS：/proc/<pid>/status 里，单位 KB，代表当前真正占着物理内存的大小；
• USS：/proc/<pid>/smaps 里 Private_Clean + Private_Dirty 之和，代表该进程独占、不可被其他进程共享的物理内存，是判断泄漏最干净的指标。
对比建议：
• 写个简单脚本每 30 秒抓一次 USS，跑几小时画趋势图，持续上涨基本就是泄漏；
• 如果 USS 稳定，但 VmRSS 暴涨，大概率是用了大量 mmap、tmpfs 或共享内存，得结合代码看分配逻辑；
• Java 进程还要额外看 JVM 堆外内存（DirectByteBuffer、Netty native buffer），它们不体现在 Java heap 里，但算在 VmRSS 中。
第三步：定位泄漏源头，按语言分策略
内存泄漏不是“内存多了”，而是“该释放的没释放”，所以得看谁在不断申请新内存却没归还。
-
C/C++ 类进程：用
pmap -x <pid>看各内存段大小，重点关注匿名映射段（[anon]）是否随时间增长；再用valgrind --tool=memcheck --leak-check=full ./your_program复现测试，它能标出 malloc 未 free 的具体行号。 -
Java 进程：先
jstat -gc <pid>看老年代是否频繁 Full GC 且回收后仍高位；再用jmap -histo:live <pid>查存活对象 Top 10；必要时jmap -dump:format=b,file=heap.hprof <pid>拿到堆快照，用 VisualVM 或 Eclipse MAT 分析引用链。 -
Python 进程：启用
tracemalloc（Python 3.4+），在程序开头加：import tracemalloc; tracemalloc.start()，出问题后调snapshot = tracemalloc.take_snapshot()，再用snapshot.statistics('lineno')定位哪行代码分配最多且未释放。
第四步：防止误杀，给关键进程加保护
即使找到泄漏，修复也需要时间。线上可先做防护，避免核心服务被连带误杀：
- 临时降低进程被杀优先级：
echo -900 > /proc/<pid>/oom_score_adj（-1000 是完全免疫，-900 是大幅降低权重） - 长期方案写进 systemd service 文件：
OOMScoreAdjust=-900，配合Restart=on-failure，既防杀又保可用性 - 检查 overcommit 设置：
cat /proc/sys/vm/overcommit_memory，值为 2 表示严格模式（Committed_AS ≤ CommitLimit），能提前暴露内存超配风险，比等 OOM 更早预警
