确认oom killer杀死进程需先执行dmesg -t | grep -i "killed process"，若输出含时间戳、pid、进程名及vmrss值则坐实；再查/proc//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 了大文件但没读，或用了大量共享库。

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

重点看这两个值：
• VmRSS：/proc//status 里，单位 KB，代表当前真正占着物理内存的大小；
• USS：/proc//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></pid> 看各内存段大小，重点关注匿名映射段（[anon]）是否随时间增长；再用 valgrind --tool=memcheck --leak-check=full ./your_program 复现测试，它能标出 malloc 未 free 的具体行号。
• Java 进程：先 jstat -gc <pid></pid> 看老年代是否频繁 Full GC 且回收后仍高位；再用 jmap -histo:live <pid></pid> 查存活对象 Top 10；必要时 jmap -dump:format=b,file=heap.hprof <pid></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</pid>（-1000 是完全免疫，-900 是大幅降低权重）
• 长期方案写进 systemd service 文件：
  OOMScoreAdjust=-900，配合 Restart=on-failure，既防杀又保可用性
• 检查 overcommit 设置：
  cat /proc/sys/vm/overcommit_memory，值为 2 表示严格模式（Committed_AS ≤ CommitLimit），能提前暴露内存超配风险，比等 OOM 更早预警