merge: main → test(反向合)

docker-compose.prod.yml

@@ -119,11 +119,17 @@ services:
     #     ────────────────────────────────────────────────
     #     可给 pac-service                        ~10 GB   → 取 8G,余下留给 OS/dockerd
     #
-    # ✅ 8G 已由生产实测证实**很宽**(2026-09-05 10:15 那轮,分批改造上线后第一轮干净数据,
-    #   550,481 召回池):**峰值 rss=2873MB,只用到 36%,2.8 倍余量,RestartCount=0 全程没被杀。**
-    #   ⚠️ 定这个数时手上只有 6.03G 那个**分批改造之前**的旧峰值(才留 33% 余量),
-    #     是分批把实际峰值又压掉一半多。⛔ 以后调这个数**必须重新量**,别拿 6.03G 当依据。
-    #     量法:`docker logs pac-pac-service-1 | grep -o "rss=[0-9]*MB heapUsed=[0-9]*MB"` 取最大。
+    # ✅ 2026-09-05 生产实测两整轮(550,481 召回池),RestartCount=0 全程没被杀:
+    #       cgroup memory.peak = 4760 MiB  ← **这才是 mem_limit 管的数**,58% of 8192,1.7 倍余量
+    #       进程 rss 峰      = 2936 MB    heapUsed 峰 = 2544 MB
+    #   ⛔ **量余量必须看 cgroup,不能看 `docker stats` 或进程 rss。**
+    #     三者差 1.6 倍:cgroup 还计入 page cache 与堆外分配,进程 rss 不含前者;
+    #     `docker stats` 是采样,峰值会漏在采样之间(实测采样只看到 3.53GiB,真实 4.65GiB)。
+    #     正确量法:`docker exec pac-pac-service-1 cat /sys/fs/cgroup/memory.peak`
+    #     (高水位自容器创建起累计,重建即清零 —— 要在一轮跑完之后、下次重建之前读)
+    #   ⚠️ 4760 里有相当部分是**可回收的** page cache(实测跑完后 file 段只剩 2 MiB),
+    #     撑到上限时内核会先回收它再谈 OOM,所以真实的不可压缩需求低于这个数。
+    #   ⚠️ 定这个数时手上只有 6.03G 那个**分批改造之前**的旧峰值。⛔ 以后调必须重新量。
     #
     # 【与下面 NODE_OPTIONS 的关系】RSS 恒大于 V8 堆(堆外还有 Buffer/Prisma engine/源码映射,
     #   实测约 560MB)。两者若相等,撞顶时**一定是先被 cgroup SIGKILL(零日志零堆栈)**,
@@ -204,9 +210,15 @@ services:
       #   而不是 V8 抛 `Reached heap limit`(有 JS 堆栈,能直接定位是哪段吃的)。
       #   等于把唯一一次能拿到现场的机会浪费掉 —— 而 09-04 整件事就是败在没有现场。
       #
-      # 6144 的依据(2026-09-05 生产 10:15 那轮实测,分批改造上线后第一轮干净数据):
-      #   峰值 heapUsed=2437MB(批 15),之后单调降到 402MB;峰值 rss=2873MB。
-      #   6144 相对实测峰值留 2.5 倍余量;最坏 RSS ≈ 6144 + 600 ≈ 6.7G < 8G ⇒ V8 先抛。
+      # 6144 的依据(2026-09-05 生产连续两整轮实测,550,481 池):
+      #   峰值 heapUsed=2544MB,之后单调降到 199MB;进程 rss 峰=2936MB。6144 留 2.4 倍余量。
+      #
+      # ⚠️ **这个"V8 先抛"不是硬保证,是大概率。** cgroup 高水位 4760MiB 比堆峰值 2544MB
+      #   多出约 2.2G(堆外分配 + page cache)。若堆真涨到 6144,总量可能逼近 8192,
+      #   届时到底是 V8 先抛还是 cgroup 先杀,取决于当时有多少 page cache 可回收。
+      #   ⇒ 想要**硬保证**就把这里降到 5120(5120+2200 < 8192);代价是相对当前峰值只剩 2.0 倍。
+      #   现在取 6144 是权衡:常见的堆失控场景下 V8 会先抛(page cache 会被先回收掉),
+      #   而 2.4 倍余量不至于把本来能跑完的轮次变成必崩。
       #
       # ⚠️ 不影响 CLI:补摄/recompute-plans 走 `node --max-old-space-size=8192 …`,
       #   命令行 V8 flag 覆盖 NODE_OPTIONS(Node 把 NODE_OPTIONS 当作排在命令行**之前**),