直接设--oom-score-adj=-500并配合--memory=1g可显著降低高价值网关容器被oom killer选中的概率，未配内存限制时该参数无效；需验证/proc/1/oom_score_adj值为-500，并建议搭配--memory-reservation和监控确保稳定性。
直接给高价值网关容器设一个足够低的 oom-score-adj 值（比如 -500），再配上明确的内存上限，就能显著降低它被 OOM Killer 选中的概率。关键不是让它“不死”，而是让它比其他容器更晚被杀。
必须搭配 --memory 才生效
单独设置 --oom-score-adj=-500 没用。内核只在容器实际内存使用超过 --memory 限制时，才启动 OOM 评估流程。没这个硬边界，评分就失去计算基础。
- 正确写法：
docker run --memory=1g --oom-score-adj=-500 ... nginx:alpine - 错误写法：
docker run --oom-score-adj=-500 ...（参数被忽略） - 建议禁用 swap：加
--memory-swap=1g，避免因 swap 延迟触发 OOM，让保护逻辑更及时
合理取值与网关场景匹配
网关通常承担流量入口、路由、鉴权等核心职责，应优先保活。参考以下典型配置：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- -500：推荐用于生产网关容器，大幅拉低被杀权重，配合 1–2GB 内存限制较稳妥
- -300：适合对延迟敏感但非绝对核心的网关变体（如灰度网关、API 聚合层）
-
避免 -1000：虽可近乎豁免 OOM，但需
--privileged且依赖内核支持，生产环境风险高，不必要
验证是否真正生效
容器启动后，进容器检查主进程（PID 1）的评分值：
- 执行：
docker exec 网关容器名 cat /proc/1/oom_score_adj - 预期输出：
-500（或你设定的值） - 若返回
0，常见原因：Docker 版本低于 20.10，或漏配--memory
配套资源策略增强稳定性
仅靠 oom-score-adj 不够，还需从资源分配层面减少触发条件：
- 设软性缓冲：
--memory-reservation=800m（当系统内存紧张时，Docker 会主动回收超出该值的部分） - 监控实际用量：
docker stats 网关容器名，确认峰值未长期逼近 limit - 避免与其他高内存容器共节点：比如把日志采集、离线任务类容器调度到其他机器
