CN2 VPS 内存占用过高导致 OOM 进程被杀怎么排查

直接确认系统日志中是否存在 OOM Killer 记录，区分是 JVM 堆内存溢出还是操作系统级内存耗尽。优先通过 dmesg 定位被杀进程 PID，再根据业务类型调整内存限制或优化代码。

先说结论：CN2 VPS 出现 OOM 进程被杀通常是物理内存 + Swap 耗尽触发内核保护机制，需先区分应用层溢出还是系统层杀进程。

命令速用版

以下命令用于快速定位 OOM 事件和当前内存状态，需在 SSH 终端以 root 或 sudo 权限执行。

# 查看内核 OOM 日志
dmesg -T | grep -i "out of memory"
# 查看系统日志中的 OOM 记录
grep -i "oom" /var/log/messages
# 查看当前内存使用情况
free -h
# 查看内存占用最高的进程
top -o %MEM

Linux 内核在物理内存和 Swap 空间耗尽时会触发 OOM Killer 机制强制终止进程。

系统不是单纯杀死占用内存最大的进程，而是根据 oom_score 评分算法选择综合得分最高者。评分取决于内存占用 RSS、oom_score_adj 调整值及运行时间。Java 应用常因堆外内存或未限制堆大小导致占用超过容器限制，从而被系统判定为最佳牺牲对象。

按照日志确认、进程分析、参数调整的顺序进行排查。

第一步：确认 OOM 类型

检查应用日志是否有 Java heap space 错误。若有，属于 JVM 内部溢出；若应用日志无异常但进程消失，且 dmesg 有记录，属于 OS 级 OOM Killer 杀进程。

第二步：定位被杀进程

在 OOM 日志中查找"Killed process XXX (pid YYY)"行，明确被终止的进程名和 PID。注意被杀进程不一定是当时 RSS 最高的，而是综合评分最高者。

第三步：调整内存策略

对于 Java 应用，限制堆内存大小，例如设置-Xmx 参数为物理内存的 50%-70%。对于关键进程，可调整 oom_score_adj 值为负数以降低被杀概率，例如 echo -1000 > /proc/[pid]/oom_score_adj。

通过持续监控内存使用率和系统日志确认问题是否解决。

使用 watch -n 1 free -h 观察 Available 内存是否稳定。再次执行 dmesg | grep -i "oom" 确认无新增记录。对于 Java 应用，观察 GC 日志频率是否恢复正常，避免频繁 Full GC。

排查过程中容易误判内存状态或采取无效优化措施。

free 命令误导：free 显示的 available 是估算值，需结合/proc/meminfo 中 Committed_AS 判断是否接近 CommitLimit。
盲目清理缓存：执行 echo 3 > /proc/sys/vm/drop_caches 会清空内核缓存，可能导致系统性能短暂下降，仅适合临时应急。
忽略堆外内存：Java 进程 VmRSS 与堆大小差值过大，可能存在 DirectByteBuffer 泄漏或线程数失控。

JVM OOM 会在应用日志抛出 OutOfMemoryError 异常且进程仍在运行。系统 OOM 会导致进程直接消失，需在 dmesg 中查看 Kill process 记录。

增加 Swap 可延缓 OOM 触发，但 Swap 读写速度慢，可能导致系统响应变慢，仅适合非性能敏感场景。

关键进程可能因 oom_score_adj 值过高被优先选中。可通过将该值设为 -1000 来保护关键服务免受 OOM Killer 影响。