【Bug已解决】OpenClaw Docker 容器 Exited 137（OOM Killed）解决方案

【Bug已解决】OpenClaw Docker 容器 Exited 137（OOM Killed）解决方案

1. 问题描述

用 Docker 部署 OpenClaw 后，容器运行一段时间会突然退出，查看容器状态显示：

$ docker ps -a CONTAINER ID STATUS abc123def456 Exited (137) 2 minutes ago

1.1 具体现象

1. 容器刚启动时运行正常，过一段时间（几分钟到几小时不等）会突然退出
2. 没有看到明显的应用层报错日志，容器就是"消失"了
3. 在处理较多渠道消息、或者接入的模型交互较频繁时更容易复现
4. 重启容器后能恢复正常运行一段时间，然后再次退出

137这个退出码本质上是128 + 9，其中9对应SIGKILL信号，几乎总是意味着容器因为内存使用超出限制，被 Linux 内核的 OOM Killer（内存溢出终结者）强制杀死。

2. 原因分析

Docker 容器可以通过--memory参数配置内存使用上限（cgroup 内存限制）。当容器内进程的实际内存占用超过这个上限时，Linux 内核的 cgroup 内存控制器会介入，选择杀死容器内占用内存最多的进程，以保护整个系统不因为单个容器耗尽内存而崩溃。

用一张流程图梳理判断逻辑：

容器运行过程中内存占用持续增长 ↓ 是否超过了容器配置的内存限制（或宿主机整体可用内存）？ ├─ 未超过 → 正常运行 └─ 超过 → cgroup OOM Killer 介入，发送 SIGKILL 强制终止进程 ↓ 容器退出，退出码 137

可以用docker inspect确认具体是容器自身的内存限制触发，还是宿主机整体内存耗尽触发：

docker inspect abc123def456 --format='{{.State.OOMKilled}}' # 返回 true 表示确实是被 OOM Killer 终止

OpenClaw 内存占用持续增长的常见原因包括：处理大量并发渠道消息、长时间运行未释放的会话上下文缓存、以及某些渠道插件本身存在的内存泄漏问题。

3. 解决方案

方案一：适当调高容器的内存限制配置

如果宿主机本身有充足的可用内存余量，最直接的方式是提高分配给容器的内存上限：

docker run -d --memory=2g --memory-swap=2g your-openclaw-image

在docker-compose.yml中配置：

services: openclaw: image: your-openclaw-image deploy: resources: limits: memory: 2G

方案二：排查并优化实际的内存消耗来源

在提高限制之前，更根本的做法是先搞清楚内存到底消耗在哪里：

# 进入容器内部，观察各进程的内存占用情况 docker exec -it abc123def456 sh top

如果发现某个特定渠道或功能模块的内存占用明显异常增长，可以针对性地评估是否存在需要优化的逻辑（比如未正确释放的历史消息缓存）。

方案三：配置容器自动重启策略，降低单次崩溃的影响

在无法立即根治内存问题的情况下，先配置好自动重启策略，确保容器被 OOM Killer 终止后能自动恢复运行，减少服务中断的时长：

docker run -d --restart=unless-stopped --memory=2g your-openclaw-image

方案四：定期重启容器，主动释放可能存在的内存泄漏累积

如果确认是长时间运行导致的渐进式内存泄漏（而非短时间内的暴涨），可以配置一个定期重启的维护策略，作为治本方案上线前的临时缓解措施：

# 通过 crontab 配置每天低峰时段主动重启一次容器 0 3 * * * docker restart abc123def456

方案五：升级到已知修复了内存泄漏问题的最新版本

如果社区或官方已经确认某个特定版本存在内存泄漏缺陷并在后续版本修复，及时升级是最根本的解决方式：

docker pull openclaw/openclaw:latest docker-compose up -d --force-recreate

4. 各方案对比总结

5. 常见问题 FAQ

5.1 如何确认是容器自身限制触发的 OOM，还是宿主机整体内存耗尽？

用docker inspect查看OOMKilled字段是否为true可以确认是容器 cgroup 层面的限制触发；如果该字段为false但容器依然异常退出，需要进一步检查宿主机整体的内存使用情况（free -h），可能是宿主机层面的全局内存压力导致内核选择性地终止了某些进程。

5.2 调高内存限制是不是"治标不治本"？

如果内存增长本身是合理的业务增长（比如处理的消息量、接入的渠道数量确实增加了），适当调高限制是合理的资源规划；但如果是不受控制的内存泄漏（内存持续增长且从不释放），单纯调高限制只是延缓问题暴露的时间，最终还是需要定位并修复真正的泄漏源头。

5.3 除了内存监控，还有什么工具能帮助更细致地分析内存占用？

可以借助 Node.js 生态的内存分析工具（如生成堆快照 heap snapshot 并用 Chrome DevTools 分析），对疑似存在内存泄漏的具体模块做更深入的排查，这类深度分析通常需要开发人员介入，适合在确认问题存在且需要根本修复时使用。

5.4 排查清单速查表

□ 1. 用 docker inspect 确认 OOMKilled 字段，判断是否为内存限制触发 □ 2. 检查宿主机整体内存使用情况，排除全局内存压力因素 □ 3. 评估当前内存限制配置是否与实际业务规模匹配 □ 4. 进入容器内部排查具体哪个环节的内存占用异常增长 □ 5. 配置容器自动重启策略，降低单次崩溃的影响时长 □ 6. 关注官方是否已发布修复已知内存泄漏问题的新版本

6. 总结

OpenClaw 容器Exited 137的本质是容器内存占用超出了配置的限制（或宿主机整体内存压力），被 Linux 内核的 OOM Killer 强制终止，本质上是一种系统资源保护机制在发挥作用。核心处理思路：

1. 先用docker inspect确认是否确实是 OOM 导致的退出，明确问题性质；
2. 排查内存消耗的具体来源，这是从根源解决问题的最佳方式，而不是简单地一味调高限制；
3. 无论是否已经定位根因，都建议配置好容器自动重启策略，作为保障服务可用性的基础措施。

最佳实践建议：为生产环境的 OpenClaw 容器建立常态化的内存使用监控（比如接入 Prometheus/Grafana 这类监控体系），能在内存问题真正导致服务中断之前就提前发现异常增长趋势，从被动响应转变为主动预防。