merge: main → test(反向合)

docker-compose.prod.yml

@@ -132,8 +132,28 @@ services:
     #      **生产根本不存在的**失败模式,把验证信号污染掉。
     #
     # ⚠️ 被 SIGKILL 会在 sync_logs 留下 status='running' 的僵尸锁 —— 靠 09-04 那条
-    #   「下一轮开跑前周期回收」自愈(sync-incremental.scheduler.ts reapStaleRunningLocks)。
-    #   ⛔ 删那条回收 = 这里每杀一次就永久卡死增量。两者是配套的。
+    #   「下一轮开跑前周期回收」自愈(sync-incremental.scheduler.ts reapStaleRunningLocks),
+    #   回收时会推一条 warning 告警(09-05 加)。
+    #   ⛔ 删那条回收 = 这里每杀一次就永久卡死增量。三者(限制/回收/告警)是配套的。
+    #
+    # 🔴 **本行引入的新风险,必读:`docker exec` 跑的 CLI 和服务共享这 8G。**
+    #   补摄 / recompute-plans 一直是 `docker exec pac-pac-service-1 node --max-old-space-size=8192 …`,
+    #   **同一个容器 = 同一个 cgroup**。加限制前:服务 4G + CLI 4.9G = 8.9G,宿主 15G 装得下;
+    #   加限制后:两者之和一旦过 8G,内核会在**这个 cgroup 内部**挑一个杀 —— 有可能杀的是服务。
+    #   ⇒ 规则没变(本来就写着"别手工并发跑全量 CLI"),但**违反的代价从'也许撑得住'变成'必然被杀'**。
+    #   ✅ 正确做法:重活单开一个**带自己上限**的容器,别 exec 进服务里 ——
+    #        docker run --rm --memory=6g --network=pac_default \
+    #          --env-file apps/pac-service/.env \
+    #          --entrypoint node pac-pac-service \
+    #          --max-old-space-size=5120 dist/cli/<名字>.cli.js …
+    #      CLI 撑爆只杀它自己,服务那 8G 一点不受影响。
+    #      (2026-09-05 在测试机实跑验证过:新容器 cgroup memory.max=自己的值、连库正常、
+    #       同时 `docker stats` 里服务仍是 8GiB 分母,互不干扰。)
+    #   ⚠️ DATABASE_URL 分形态:
+    #      · 托管 DB(本生产机 friday)—— .env 里就是 RDS 地址,`--env-file` 足够;
+    #      · 自带 PG(测试机)—— .env 里是 localhost,单开的容器连不上,须另加
+    #        `-e DATABASE_URL=postgresql://$POSTGRES_USER:$POSTGRES_PASSWORD@postgres:5432/$POSTGRES_DB?schema=public`
+    #   ⚠️ 真要 exec 进服务容器,先确认没在跑轮次(cron `15 0,8-22/2 * * *` 沪),并盯 `docker stats`。
     mem_limit: 8g
     depends_on:
       postgres: