OOM误杀本质是关键服务未声明重要性，需通过oom_score_adj调优、排查子网关联资源倾斜及内存行为模式来验证与解决。
子网划分本身不直接导致 OOM 误杀，但当网络架构与资源调度耦合紧密时（如 K8s 中按子网划分节点池、服务网格按子网隔离流量），子网配置不当可能间接加剧内存压力分布不均，进而放大 OOM Killer 误判风险。排查核心服务被误杀，重点不是查子网掩码或 IP 分配，而是厘清「子网关联的资源边界是否引发内存争抢」。
确认是否真为 OOM 误杀，而非正常淘汰
先排除误判：执行 dmesg -T | grep -i "killed process"。若输出含 "Killed process XXX (java/nginx) score NNN"，且被杀进程是数据库、etcd、coredns 或自定义关键服务（非临时任务进程），再继续；若没匹配结果，问题不在 OOM。
注意两个关键信号：
- score 值高（如 >800）但进程 RSS 并非系统最高——说明 OOM Killer 综合了运行时长、特权等级、子进程开销等打分，并非单纯看内存
- 同一子网内多个节点在相近时间点连续出现不同进程被杀——提示该子网共用的底层资源（如共享宿主机、统一监控 agent、同一批 DaemonSet）存在隐性内存泄漏
检查子网关联的节点/实例是否存在资源倾斜
子网常对应物理区域或云厂商可用区（AZ），而 AZ 内节点可能共用硬件资源（如超卖宿主机）、统一部署组件（如日志采集器 fluentd、安全策略 agent）。排查路径：
- 列出该子网下所有节点：kubectl get nodes -o wide | grep
，再查各节点内存压力：kubectl top node - 对比各节点 /proc/meminfo 中的 Committed_AS / CommitLimit 比值，>95% 的节点需优先关注
- 检查该子网节点是否统一运行了高内存波动组件（如 Prometheus 抓取目标过多、ELK 日志解析规则复杂），它们可能未设 memory limit，挤占核心服务空间
验证关键服务是否被降权保护
OOM Killer 不会“误杀”，只按算法选分最高者。所谓“误杀”，本质是关键服务未主动声明其重要性。必须做两件事：
- 为容器设置 oom_score_adj = -1000（完全免疫）或 -500（大幅降低优先级）：在 Pod spec 中添加 securityContext.oomScoreAdj: -500
- 确认该服务未因子网策略被强制注入高内存开销 sidecar（如某服务网格默认开启全量 TLS 加密+日志采样，而其他子网关闭）——检查 kubectl get pod -o yaml 中 containers 数量和资源 request/limit 是否异常多出一个
结合子网拓扑复盘内存增长源头
如果故障集中在某子网，不要只查单个被杀进程，要查该子网整体内存行为模式：
- 用 smem -w -k -c "pid user command pss uss" 对比同子网不同节点的 USS 分布，看是否某类进程（如 java、postgres、node）在特定子网 USS 持续偏高
- 检查该子网是否承载了特殊流量：例如灰度发布子网接入了新版本客户端，其请求触发了旧服务中未修复的内存泄漏路径；或该子网 DNS 解析指向了异常慢的上游，导致连接池堆积、缓冲区膨胀
- 查看该子网节点上 /proc/sys/vm/overcommit_memory 设置是否与其他子网不一致（如部分节点设为 1 允许过度分配，而核心服务所在节点为 2 严格限制），造成资源感知错位
