关键不是让容器“不死”，而是让内核在内存告急时清楚地知道：哪些该先退、哪些必须留到最后。--oom-score-adj 通过 -1000 到 +1000 的数值为容器设定“生存权重分”，-500 保护核心服务，+300～+500 优先牺牲次要容器，且必须配合 --memory 才生效，否则参数被忽略；验证方式为 cat /proc/1/oom_score_adj 返回设定值。
关键不是让容器“不死”，而是让内核在内存告急时清楚地知道：哪些该先退、哪些必须留到最后。--oom-score-adj 的作用，就是给每个容器打一个“生存权重分”，配合内存限制一起用，才能真正生效。
数值设定要匹配角色重要性
这个参数取值范围是 -1000 到 +1000，0 是默认值，代表和宿主机普通进程同等优先级：
- -500：适合数据库、核心 API、监控采集器（如 node-exporter）等不可中断服务；能显著降低被杀概率，又保留极端情况下的系统可控性
- 0：业务应用默认值，不额外干预，按实际内存占用参与评分
- +300～+500：适合日志聚合、离线计算、临时调试容器；内存吃紧时优先释放
- -1000：仅限特权容器且需内核支持，等于告诉内核“别动它”；生产环境慎用，会削弱系统最后兜底能力
必须搭配 --memory 才起作用
没有内存上限，oom_score_adj 就像没有标尺的刻度——内核根本不会对单个容器启动 OOM 评估：
- 只设
--oom-score-adj=-500不设--memory：参数被忽略，容器可能和宿主机其他进程一起被随机杀死 - 正确写法示例：
docker run --memory=2g --oom-score-adj=-500 redis:7-alpine - 若启用 swap，建议显式加
--memory-swap=2g（即禁用 swap），避免延迟触发 OOM
验证是否生效很简单
容器启动后，进容器执行一句命令就能确认：
-
cat /proc/1/oom_score_adj—— 应返回你设定的数值（比如 -500） - 注意：查看的是 PID 1 进程的值，不是 shell 或子进程
- 若返回 0 或其他值，检查 Docker 版本是否 ≥20.10，或是否遗漏了权限/运行时配置
Kubernetes 场景下用 oomScoreAdj 字段
在 Pod YAML 中直接配置，kubelet 会自动透传到底层运行时（containerd 或 Docker）：
- 写法示例：
securityContext: { oomScoreAdj: -500 } - 必须同时设置
resources.limits.memory，否则无效 - 适用于 Kubernetes v1.20+，无需额外插件或 runtimeClass
