--oom-score-adj用于控制容器在内存超限时被oom killer杀死的优先级,数值越低越靠后被杀,但必须配合--memory才生效;-500适用于核心服务,+300~+500用于临时任务,-1000需特权且慎用。

直接用 --oom-score-adj 控制容器在内存极载时被内核 OOM Killer 杀死的先后顺序,数值越低越靠后被杀,但必须搭配 --memory 才真正生效。
必须配内存限制,否则参数无效
OOM Killer 只在容器内存使用超出 --memory 设定值时才启动评估。没这个硬边界,内核不会对单个容器做 OOM 判定,--oom-score-adj 就完全不参与决策。
- 只设
--oom-score-adj=-500不设--memory:参数被忽略,容器可能和宿主机其他进程一起被随机杀死 - 正确组合示例:
--memory=1g --oom-score-adj=-500,此时该容器在超限时有更高生存权重 - 若同时启用 swap,建议显式设
--memory-swap=1g(即禁用 swap),避免延迟触发 OOM
常用取值与对应角色
数值范围是 -1000 到 +1000,0 是默认值,代表和宿主机普通进程同等优先级。
- -500:推荐用于数据库、核心 API 等关键服务,显著降低被终止概率
- 0:默认,适用于常规业务容器,无额外保护
- +300~+500:适合日志采集、定时导出等临时任务,内存紧张时优先让出资源
-
-1000:完全豁免 OOM Killer,仅限特权容器(
--privileged)且需内核支持CONFIG_OOM_DISABLE,生产环境慎用
验证是否生效
容器启动后,进入容器检查主进程(PID 1)的评分值:
- 执行:
docker exec 容器名 cat /proc/1/oom_score_adj - 应返回你设定的值(如 -500);若返回 0 或其他值,常见原因是 Docker 版本低于 20.10,或漏配
--memory - 注意:cgroup v2 环境下该路径可能不可见,此时应确保使用 Docker 20.10+ 并依赖启动参数而非手动写入
别和 --oom-kill-disable 混用
--oom-kill-disable 是全局禁用 OOM Killer,风险极高:
- 一旦容器内存失控,可能耗尽宿主机全部内存,拖垮整个系统
- 它不区分容器重要性,是“一刀切”,无法实现分级牺牲
- 生产环境应始终保留 OOM Killer,靠
--oom-score-adj + --memory实现可控的优先级调度











