禁用 oom killer 并非保护高价值容器的推荐方式，应通过 --oom-score-adj 分级调控优先级，并配合 --memory 和 --memory-reservation 实现安全弹性控制。
--oom-kill-disable=true 确实能阻止内核在内存耗尽时杀死容器进程，但它不是“保护高价值容器”的推荐方式——它更像一把双刃剑：表面保命，实则埋雷。真正安全、可控的做法是分级调控 oom 优先级，而非一刀切禁用。
必须配合 -m（即 --memory）使用
--oom-kill-disable=true 在 Docker 中是有条件生效的：
- 若未设置内存限制（如
-m 512m），该参数会被忽略，容器仍可能被杀； - 即使设了
-m，禁用 OOM Killer 后，当内存彻底耗尽，容器会被挂起（OOM-killer 不杀，但 cgroups 冻结进程），表现为无响应、无法调度、日志卡死，比被杀更难排查； - 宿主机可能因资源僵死而整体变慢，甚至影响其他关键服务（包括 Docker daemon 自身）。
生产环境更推荐用 --oom-score-adj 做精准分级
这才是保护高价值容器的核心手段：
- 关键服务（如 MySQL、核心 API）设为
-500：显著降低被选中的概率； - 次要任务（如日志清洗、报表生成）设为
+400：主动让出资源； - 所有容器都必须配
--memory，否则oom-score-adj无效（内核只对受控进程做评分）； - 示例命令：
docker run -d \ --name mysql-prod \ --memory=2g \ --oom-score-adj=-500 \ -e MYSQL_ROOT_PASSWORD=123 \ mysql:8.0
配合软限制提升弹性
光靠 OOM 调整还不够，建议叠加 --memory-reservation：
- 设定一个“建议保留值”，比如
--memory-reservation=1.5g（低于--memory=2g）； - 当系统内存紧张时，Docker 会优先压缩超出 1.5G 的部分，而不是等爆到 2G 才触发 OOM；
- 这相当于给关键容器多一层缓冲，减少极端场景下的 Kill 概率。
补充建议：避免误判的底层动作
- 检查宿主机
vm.overcommit_memory设置：若为2，需同步调高vm.overcommit_ratio，防止内核过早拒绝内存分配； - Java/Python 类容器务必在应用层做内存约束（如
-Xmx1g、--ulimit memlock），否则 OOM 控制形同虚设； - 定期用
docker stats或ps -eo pid,comm,oom_score | sort -k3 -nr观察实际评分分布，验证策略是否生效。
不复杂但容易忽略
