--oom-kill-disable不能防止容器意外终止，它仅将整容器终止改为随机杀进程，更不可控；真正可靠的是合理配置--memory、--memory-reservation和--memory-swap以预防OOM。
不能靠 --oom-kill-disable 防止容器被“意外终止”——它只是把“容器被杀”换成“容器内进程被随机杀死”，反而更不可控。真正防止意外终止，靠的是合理设置内存硬限制和预留空间，而不是关掉保护机制。
为什么 --oom-kill-disable 不是安全选项
该参数的作用是：当容器内存超限时，内核不再直接终止整个容器，而是退而求其次，在容器内部挑一个进程（通常是内存占用大的）用 OOM Killer 杀掉。结果往往是主进程（如 nginx worker、Java 应用）被干掉，容器却还“活着”——表现为持续崩溃重启、响应异常或静默失败。
- 必须配合
--memory使用，否则宿主机可能因内存耗尽而卡死甚至宕机 - 需要特权模式（
--privileged）或 root 权限，多数生产环境禁用 - 关闭后失去快速失败信号，掩盖真实内存问题（比如泄漏、配置过小）
真正防意外终止的三个关键配置
稳定运行的核心不是“不让杀”，而是“别让系统走到要杀的地步”。重点在预防和缓冲：
- --memory=512m：设硬上限，强制容器无法突破物理内存边界
- --memory-reservation=300m：设软目标，告诉 Docker “尽量别超过 300MB”，系统内存紧张时优先压缩这类容器
-
--memory-swap=512m：显式禁用 swap（即
swap = 0），避免因交换延迟导致响应恶化或误判
OOM 发生时该怎么排查
如果容器频繁出现 ExitCode 137 或日志里有 OOM killed，说明限制已生效但配额不合理：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 用
docker stats <container>观察 MEM % 是否长期接近 100% - 检查应用自身是否有内存泄漏（如 Java 的 heap 持续增长、Node.js 的对象未释放）
- 对比 MEM USAGE / LIMIT 和实际业务负载：流量高峰时是否刚好触顶？
- 临时调高
--memory并加--memory-reservation观察是否稳定，再反推合理值
docker-compose 中的等效写法
在 deploy.resources.limits 下不支持 --oom-kill-disable，但可精确控制内存行为：
deploy:
resources:
limits:
memory: 512M
reservations:
memory: 300M注意：oom_kill_disable 属于 runtime 级参数，需在 mem_reservation 后单独声明（部分旧版 Compose 不支持，建议用 v2.23+）：
mem_reservation: 300M oom_kill_disable: false # 显式保持启用，才是稳妥做法
