企业官网建设流程全解析

prompts.chat Docker 首次构建出现 “Killed” 和 “exited with code 137” 怎么排查？

【免费下载链接】prompts.chatf.k.a. Awesome ChatGPT Prompts. Share, discover, and collect prompts from the community. Free and open source — self-host for your organization with complete privacy.项目地址: https://gitcode.com/GitHub_Trending/aw/prompts.chat

第一次用 Docker Compose 启动 prompts.chat 时，如果构建日志里先出现Killed，紧接着容器以exited with code 137退出，仓库的 DOCKER.md 已明确给出判断：Docker 容器在构建阶段内存耗尽（OOM）。首次构建需要比运行时更高的内存，内存限额过低时就会触发这个现象。本文按仓库文档说明完整的判定、修复（调高 Docker 内存分配）与重启后验证方法。

先确认是 “Killed + 137” 这一类内存问题

Killed+exited with code 137在 DOCKER.md 中对应的是首次启动时的内存不足，而不是数据库或认证问题。判定前先看日志确认现象出自哪个服务：

# 全部服务的日志 docker compose logs # 只看应用容器 docker compose logs app

需要对照的是 DOCKER.md 给出的资源要求。运行时的要求是 1 CPU 核心、1GB RAM、2GB 磁盘；而首次构建（First-run build，含 Next.js 编译）的要求是 1 CPU 核心、更高的内存（原文：Higher memory required (OOM may occur with low limits)）、2GB 磁盘。也就是说，内存限额只够运行时、不够首次构建时，就会出现Killed后exited with code 137。本地构建（docker compose up -d --build，构建逻辑见 docker/Dockerfile）和首次启动预构建镜像都会走首次构建路径，都可能遇到该现象。

调高 Docker 的内存分配

DOcker.md 给出的处理方式是调大 Docker 的内存配额，示例值为约 4GB 或更高：

Increasing Docker's memory allocation (e.g., ~4GB or more) can help resolve this.

文档给出的具体操作路径是 Docker Desktop：Settings → Resources → Memory。注意两点：

• 这是修改 Docker 运行环境的资源分配，不是修改仓库里的 compose.yml；compose.yml 本身没有内存限制相关配置。
• 文档只给出了 Docker Desktop 的设置路径，其他平台（如自管的 Docker 引擎）按各自的环境管理方式调整，仓库文档未展开。

重新构建并启动

调高内存后直接重跑启动命令即可，数据不会丢失：PostgreSQL 数据存放在postgres_data命名卷中，文档明确其 “persists across container restarts, rebuilds, and image updates”，所以因 OOM 失败后重新构建不会丢库。

本地构建（首次使用的主路径）：

docker compose up -d --build

如果使用预构建镜像（不带--build）：

docker compose up -d

验证构建与启动成功

1. 用docker compose ps查看服务状态，同时确认db服务处于 healthy（数据库健康检查见 compose.yml 中的healthcheck配置）。
2. 请求健康检查端点：

curl http://localhost:4444/api/health

正常时返回文档示例（时间戳为实际值，下面是 DOCKER.md 中的示例输出）：

{ "status": "healthy", "timestamp": "2024-01-01T00:00:00.000Z", "database": "connected" }

从 健康检查路由 的实现看，该端点会执行一次数据库查询：数据库连接正常返回status: "healthy"；连接失败则返回 503 和database: "disconnected"。所以这一步同时验证了应用启动和数据库连通性。

3. 最后打开 http://localhost:4444，能正常访问页面即完成首次启动。

现象不是 Killed/137 时的对照排查

如果容器反复重启但日志里没有Killed/137，就不要按内存问题处理，按 DOCKER.md 的 Common Issues 区分：

• 应用容器一直重启：先查docker compose logs app。数据库可能尚未就绪——入口脚本 docker/entrypoint.sh 会重试数据库连接，最多约 60 秒（30 次、每次间隔 2 秒），超过后才会报错退出。
• 数据库连接错误：用docker compose ps确认db服务是否 healthy，再看docker compose logs db。

这两类现象与Killed/137 的根因不同，日志特征是区分依据。

边界说明

• 文档给出的内存建议是 “~4GB or more” 的示例值，用于说明“需要调大内存”的方向，不是精确阈值；如果你的 Docker Desktop 可用内存有限，可结合首次构建时的实际表现逐步上调。
• DOCKER.md 同时给出了生产建议配置（2 CPU 核心、2GB RAM 运行时、10GB 磁盘），可一并参考。
• 仓库文档未提供查看容器当前内存用量的命令，排查路径就是“日志确认 137 现象 → 调大内存 → 重建 → 健康检查验证”。

【免费下载链接】prompts.chatf.k.a. Awesome ChatGPT Prompts. Share, discover, and collect prompts from the community. Free and open source — self-host for your organization with complete privacy.项目地址: https://gitcode.com/GitHub_Trending/aw/prompts.chat