修复完整容器数据库内存上限
将完整容器 SpacetimeDB 内存上限提升到 2 GiB 增加基础 Compose 内存门禁 同步容器运维文档与项目长期记忆
This commit is contained in:
@@ -13,7 +13,7 @@ Docker Compose
|
||||
└─ otelcol :4317/4318，debug exporter，接收 traces / metrics / logs
|
||||
```
|
||||
|
||||
当前容器模拟参数按 `genarrative-release` 服务器采样值收口为 2 vCPU / 2 GiB RAM / 4096 soft nofile / 768 worker_connections，并已在 compose 里落实到 `spacetimedb cpus=1.0 mem_limit=896m`、`api-server cpus=2.0 mem_limit=1g`、`external-generation-worker cpus=2.0 mem_limit=1g`、`nginx cpus=0.5 mem_limit=128m`、`otelcol cpus=0.25 mem_limit=128m`。SpacetimeDB 同时设置 `--page_pool_max_size=402653184`，给 reducer、订阅与运行时保留更多非 page pool 内存。
|
||||
当前容器模拟参数按 `genarrative-release` 服务器采样值保留 CPU、`nofile` 与 Nginx 连接口径，并已在 compose 里落实到 `spacetimedb cpus=1.0 mem_limit=2g`、`api-server cpus=2.0 mem_limit=1g`、`external-generation-worker cpus=2.0 mem_limit=1g`、`nginx cpus=0.5 mem_limit=128m`、`otelcol cpus=0.25 mem_limit=128m`。SpacetimeDB 同时设置 `--page_pool_max_size=402653184`，给 reducer、订阅与运行时保留更多非 page pool 内存；当前完整模块首次实例化的 cgroup 峰值会超过旧 `896m` 上限，因此完整容器和分支预览统一使用 `2g`，避免 publish 期间被 OOM 杀死。
|
||||
容器 `api-server` 默认 `GENARRATIVE_API_WORKER_THREADS=4`，用于让 Tokio 在 2 vCPU 配额内有更多 I/O 调度 worker；该值不会突破 compose 里的 `cpus=2.0` CPU 上限。
|
||||
容器默认 `GENARRATIVE_EXTERNAL_GENERATION_MODE=queue`，用于验证不经过 BgFilter 的 `api-server -> external_generation_job -> external-generation-worker` 链路；会触发 BgFilter 的任务不属于当前 compose 验收范围。如只想本地同步排查非 BgFilter provider / OSS / SpacetimeDB 写回，可在本机 env 临时改为 `inline`，但该模式不会覆盖 worker 动态扩缩容验证。
|
||||
Collector 镜像使用 `otel/opentelemetry-collector-contrib:0.151.0`。
|
||||
|
||||
@@ -16,7 +16,7 @@ services:
|
||||
"--non-interactive",
|
||||
]
|
||||
cpus: "1.0"
|
||||
mem_limit: 896m
|
||||
mem_limit: 2g
|
||||
ports:
|
||||
- "${GENARRATIVE_CONTAINER_SPACETIME_PORT:-13101}:3101"
|
||||
volumes:
|
||||
|
||||
@@ -14326,6 +14326,12 @@
|
||||
- 锁与平台：删除 AGC 和 Spine 子 lock；统一根 lock 必须保留 optional、bundled 和跨平台二进制节点。Linux 干净安装不能替代 Windows AGC sidecar、Android Expo/EAS 或可用 macOS/iOS runner 的平台构建证据。
|
||||
- 权威方案：`docs/technical/【技术方案】npm-workspaces统一依赖边界-2026-08-21.md`。
|
||||
|
||||
## 2026-08-22 完整容器 SpacetimeDB 内存上限统一为 2 GiB
|
||||
|
||||
- 决策：`deploy/container/docker-compose.loadtest.yml` 的 SpacetimeDB `mem_limit` 从旧压测采样值 `896m` 调整为 `2g`，与分支预览 override 一致；CPU、page pool、API、worker、Nginx 与 Collector 配额保持不变。
|
||||
- 依据：当前完整模块首次 publish / init 的进程 RSS 会超过 `896m`，cgroup 会直接 OOM kill `spacetimedb-standalone`，客户端表现为上传连接提前关闭，后续重试连接拒绝。提高 ping 或 publish 重试次数不能修复内存上限。
|
||||
- 边界：这是本地/预发完整容器的模块实例化门槛，不修改生产服务资源合同；门禁同时锁定基础 Compose 与预览 override 均为 `2g`。
|
||||
|
||||
## 2026-08-22 Jenkins 预览只向 API 运行镜像内置固定 secrets
|
||||
|
||||
- 决策：预览 secrets 权威源固定为 Jenkins 宿主 `/data/jenkins/preview-secrets/.env.secrets.local`；目录 / 文件由 Jenkins 运行账号所有且权限分别为 `0700` / `0600`，缺失、链接、非普通文件、owner 异常或权限过宽时构建失败关闭。
|
||||
|
||||
@@ -4831,3 +4831,10 @@
|
||||
- 原因：BuildKit secret mount 只避免秘密作为 `ARG` / `COPY` 进入构建上下文和中间指令；一旦 Dockerfile 把 mount 的内容安装到最终 rootfs，任何能读取、保存或运行该镜像的主体都可以提取它。
|
||||
- 处理：预览固定 secrets 只从 Jenkins 宿主受控路径读取，严格校验目录 `0700`、文件 `0600`、owner、普通文件与非链接边界；只将其安装到 `api-runtime:/srv/genarrative/.env.secrets.local` 并设为 `0400`，明确排除 Nginx、Web、artifact 和其它镜像。镜像禁止推送或导出到跨信任边界。
|
||||
- 更新与验证：源文件变更不会改动已存镜像，必须重建并替换容器；不能用重启代替。验收同时扫描 transcript/context/artifact 零泄漏，检查只有 API 最终 rootfs 存在目标文件，并验证容器显式运行 env 优先覆盖内置值。
|
||||
|
||||
## SpacetimeDB ping 健康不代表完整模块能在内存上限内实例化（2026-08-22）
|
||||
|
||||
- 现象：空库 `/v1/ping` 已成功且容器显示 healthy，但 `spacetime publish` 在 `Publishing module...` 后连接提前关闭，紧接着端口拒绝连接。
|
||||
- 原因：当前完整模块 init 的 RSS 会超过基础 Compose 旧 `896m` cgroup 上限；内核 OOM kill SpacetimeDB，客户端只看到传输错误，容易被误判为网络竞态。
|
||||
- 处理：先查 kernel journal 的 `Memory cgroup out of memory` 和目标容器 ID，再把本地/预发完整容器 SpacetimeDB 上限统一为 `2g`；保留 page pool 限制。不要只增加 publish 重试，也不要把 `/healthz` 或首页改成数据库就绪探针。
|
||||
- 验证：用新空卷完成模块 publish、五服务启动和 Web/API smoke，并确认容器未 OOM、SpacetimeDB 与 API/Nginx 最终 healthy。
|
||||
|
||||
@@ -45,7 +45,7 @@ SpacetimeDB 与 OTLP 不映射宿主端口；Jenkins 通过受控 Compose 网络
|
||||
|
||||
SpacetimeDB 2.7 CLI 发布到受控 Compose 网络地址时固定使用 `--yes=remote,migrate,break-clients`，避免 Jenkins 等待非本地目标交互确认；该预览路径不传 `--delete-data`。Jenkins 同时固定 `GENARRATIVE_PREVIEW_WEB_HOST=192.168.35.82`，不得用默认路由自动探测结果生成页面链接，以免 VPN 或容器网卡地址泄漏到同事可见 URL。
|
||||
|
||||
预览 Compose override 将 SpacetimeDB 内存上限设为 `2g`。基础 loadtest Compose 的 `896m` 是压测采样口径，当前完整模块首次发布和实例化会超过该上限；预览环境若沿用该值，容器会被 cgroup OOM 杀死并使模块上传中断。该覆盖只作用于分支预览实例，不修改生产或压测基线。
|
||||
基础 loadtest Compose 与预览 Compose override 都将 SpacetimeDB 内存上限设为 `2g`。当前完整模块首次发布和实例化的 cgroup 峰值会超过旧 `896m` 上限；完整容器或预览环境若沿用旧值，容器会被 OOM 杀死并使模块上传中断。预览 override 继续显式锁定该值并取消宿主端口映射；这不修改生产服务资源合同。
|
||||
|
||||
每个预览实例使用独立 SpacetimeDB 空库，不继承生产账号数据。Jenkins 在实例私有 `api-server.env` 中开启预览专用认证：未注册的中国大陆手机号首次使用 6 到 128 位密码时自动创建预览账号；短信入口强制使用 `mock` provider 与固定预览验证码 `123456`，不调用镜像内置的真实短信凭据。该预览认证覆盖不写入公共 env 示例或生产配置；实例重建会重建独立数据库，原预览账号不保留。
|
||||
|
||||
|
||||
@@ -683,7 +683,7 @@ worker 被硬杀或断电后，lease 过期任务只有尚未耗尽 `max_attempt
|
||||
- Nginx `/api/` 与 `/admin/api/` 通过 `genarrative_api` upstream 代理到 `127.0.0.1:8082`，upstream keepalive 为 64；通用 API 使用 `genarrative_api_rps`，后台 API 使用 `genarrative_admin_rps`。通用 `/api` location 保留 `client_max_body_size 64m` 作为编辑器图片、视频和文档请求的反代兜底，真实大小仍由路由与业务校验负责。若线上出现 `413 Request Entity Too Large` 且 access log 中 `request_time=0.000`、`upstream_status=-`，说明请求在 Nginx 层被拦截，先核对 release 模板与实际媒体大小。`limit_conn_status 429` 和 `limit_req_status 429` 必须在 HTTP 与 HTTPS server 中同时生效。
|
||||
- 旧作品列表 K6 脚本、gallery 专属限流分组和对应容量结论已经退役；源码只作历史记录，不得作为当前发布门禁。新的容量验收必须针对现役编辑器、项目和素材 API 单独建立数据、负载与指标口径。
|
||||
|
||||
容器化隔离部署方案单独放在 `deploy/container/`，用于本机或预发模拟现有的 Linux release + Nginx + OTLP Collector 非 BgFilter 拓扑，不替换当前生产 `systemd + Nginx + Jenkins` 发布路径。当前 compose 没有 `bgfilter-worker`，不构成完整 BgFilter 预发拓扑，也不覆盖任何会触发 BgFilter 的现役任务；它只用于非 BgFilter 路径，或通过下述 unsupported job smoke 验证外部生成队列的 claim / fail 回写和 API-only 更新。当前容器模拟参数按 `genarrative-release` 采样值收口为 2 vCPU / 2 GiB RAM / `nofile=4096` / `worker_connections=768`，并在 compose 里落实到 `spacetimedb cpus=1.0 mem_limit=896m`、`api-server cpus=2.0 mem_limit=1g`、`external-generation-worker cpus=2.0 mem_limit=1g`、`nginx cpus=0.5 mem_limit=128m`、`otelcol cpus=0.25 mem_limit=128m`。容器 `api-server` 默认 `GENARRATIVE_API_WORKER_THREADS=4`，只增加 Tokio worker 调度并发，不突破 `api-server cpus=2.0` 的 CPU 配额；容器默认 `GENARRATIVE_EXTERNAL_GENERATION_MODE=queue`，可用 `npm run container:up -- --scale external-generation-worker=N external-generation-worker` 验证不经过 BgFilter 的外部生成 worker 动态扩缩容，`inline` 模式不参与该验证：
|
||||
容器化隔离部署方案单独放在 `deploy/container/`，用于本机或预发模拟现有的 Linux release + Nginx + OTLP Collector 非 BgFilter 拓扑，不替换当前生产 `systemd + Nginx + Jenkins` 发布路径。当前 compose 没有 `bgfilter-worker`，不构成完整 BgFilter 预发拓扑，也不覆盖任何会触发 BgFilter 的现役任务；它只用于非 BgFilter 路径，或通过下述 unsupported job smoke 验证外部生成队列的 claim / fail 回写和 API-only 更新。当前容器模拟参数保留 `genarrative-release` 的 CPU、`nofile=4096` 与 `worker_connections=768` 采样口径，并在 compose 里落实到 `spacetimedb cpus=1.0 mem_limit=2g`、`api-server cpus=2.0 mem_limit=1g`、`external-generation-worker cpus=2.0 mem_limit=1g`、`nginx cpus=0.5 mem_limit=128m`、`otelcol cpus=0.25 mem_limit=128m`。完整模块首次实例化会超过旧 `896m` cgroup 上限，因此 SpacetimeDB 必须使用 `2g`；这不改变生产服务资源合同。容器 `api-server` 默认 `GENARRATIVE_API_WORKER_THREADS=4`，只增加 Tokio worker 调度并发，不突破 `api-server cpus=2.0` 的 CPU 配额；容器默认 `GENARRATIVE_EXTERNAL_GENERATION_MODE=queue`，可用 `npm run container:up -- --scale external-generation-worker=N external-generation-worker` 验证不经过 BgFilter 的外部生成 worker 动态扩缩容，`inline` 模式不参与该验证：
|
||||
|
||||
```bash
|
||||
npm run container:init
|
||||
|
||||
@@ -119,6 +119,11 @@ assertIncludes(
|
||||
'spacetimedb:\n mem_limit: 2g\n ports: !reset []',
|
||||
'预览 SpacetimeDB 必须覆盖压测基线内存限制，避免模块首次加载时 OOM。',
|
||||
);
|
||||
assertIncludes(
|
||||
compose,
|
||||
' mem_limit: 2g\n ports:',
|
||||
'完整容器 SpacetimeDB 必须允许当前模块首次实例化的内存峰值。',
|
||||
);
|
||||
assertIncludes(
|
||||
deployer,
|
||||
'external-generation-worker:\n build:',
|
||||
|
||||
Reference in New Issue
Block a user