排查oom误杀核心服务的关键是分析oom_score_adj配置与实际内存贡献，而非仅看rss大小；需通过dmesg定位被杀进程及其评分，用smem查pss、smaps析虚拟预留，并核验committed_as是否超限。
排查 OOM 机制误杀核心服务，关键不是“谁占内存多”，而是“谁被内核选中了，以及为什么偏偏是它”。Linux 的 OOM Killer 不按 RSS 排名杀进程，而是依据 oom_score_adj（用户可调）和实际内存消耗综合打分。误杀往往发生在：核心服务内存使用波动大、启动时预留空间多、或被错误赋予高 oom_score_adj 值，而真正吃内存的后台任务反而得分低。
看懂 OOM 日志，锁定“被杀逻辑”
系统触发 OOM 后，第一手证据在内核日志里：
- 运行 dmesg -T | grep -i "killed process"，找到带时间戳的完整 OOM 记录
- 重点确认三行："Killed process XXX (pid YYY)"（被杀进程）、"oom_score_adj: ZZZ"（它的得分）、"Mem-Info" 快照（当时匿名页、slab、页表等占用情况）
- 特别注意：如果被杀进程 RSS 只有 200MB，但同机有个 Python 脚本 RSS 占 3GB 却没被杀，说明它的 oom_score_adj 很可能被设为负值（如 -1000），而你的服务是默认 0 或正数
查清进程真实内存贡献，别被 VIRT/RSS 带偏
Java、Node.js、Go 等进程常出现“VIRT 很大、RSS 中等、PSS 才真实”的情况。OOM Killer 算分时参考的是实际物理页占用，但会加权共享页和页表开销：
- 用 smem -w -k -c "pid user command pss uss swap" 查 PSS（比例集大小），比 RSS 更公平反映单个进程对内存的真实压力
- 检查该进程是否大量 mmap 未使用区域（如 JVM 堆外内存、大文件映射），执行 cat /proc/PID/smaps | awk '/^Size:/ {s+=$2} /^MMU/{m+=$2} END{print "Total Size:", s, "MMU pages:", m}'，若 Size 远大于 VmRSS，说明存在大量虚拟地址预留
- 对 Java 服务，确认是否启用了 -XX:+UseContainerSupport（尤其在 K8s 中），否则 JVM 可能按宿主机内存计算堆大小，导致过度预留
验证 oom_score_adj 设置与调度优先级
很多核心服务（如数据库、消息队列）默认没有保护，一旦内存紧张就成首选目标。这不是内核 bug，而是配置缺失：
- 查当前值：cat /proc/PID/oom_score_adj，默认为 0；-1000 表示永不被杀，+1000 表示最优先被杀
- 临时加固：echo -900 > /proc/PID/oom_score_adj（需 root）
- 持久化方案：在 systemd service 文件中添加 OOMScoreAdjust=-900；或容器中通过 securityContext.oomScoreAdj: -900 设置（K8s）
- 注意：不要盲目设 -1000，某些内核线程或 init 进程才应享此特权；-900 已足够让普通业务进程在多数场景下跳过 OOM 选择
结合 Committed_AS 判断是否真缺内存，还是参数误导
OOM 触发不一定等于物理内存耗尽。Linux 允许“过度提交”（overcommit），当已承诺内存（Committed_AS）超过 CommitLimit，内核就会启用 OOM Killer：
- 运行 grep -E "(Committed_AS|CommitLimit)" /proc/meminfo
- 若 Committed_AS 接近或超过 CommitLimit，说明问题出在“承诺太多”，而非“物理不够”。此时应检查是否有大量 fork() 进程、未限制的容器 limits、或应用频繁申请大块虚拟内存却未使用
- 临时缓解：调整 vm.overcommit_memory=2 并设 vm.overcommit_ratio=80（表示最多承诺 80% 物理内存 + swap），避免激进 overcommit
