docker-compose.prod.yml
16.9 KB
-
perf(ops): 堆上限 8192→6144 —— 让撞顶时 V8 先抛(有堆栈)而不是被 cgroup 静默杀 · cfb6e16b
加了 mem_limit(8g)后,堆上限还留在 8192 会形成一个坏顺序:RSS 恒大于堆 (实测 rss=2873MB 时 heapTotal=2309MB,堆外常驻约 560MB),两者相等时 **一定是先撞 cgroup 被 SIGKILL —— exit 137,零日志零堆栈**,而不是 V8 抛 `Reached heap limit`(带 JS 堆栈,能直接定位是哪段吃的)。 等于把唯一一次能拿到现场的机会浪费掉,而 09-04 整件事就是败在没有现场。 6144 的依据是生产实测,不是拍脑袋 —— 09-05 10:15 那轮(分批改造上线后第一轮 干净数据,550,481 召回池):峰值 heapUsed=2437MB(批 15),之后单调降到 402MB; 峰值 rss=2873MB。6144 相对峰值留 2.5 倍;最坏 RSS ≈ 6144+600 ≈ 6.7G < 8G ⇒ V8 先抛。 不影响 CLI:命令行 --max-old-space-size 覆盖 NODE_OPTIONS,已实测 (NODE_OPTIONS=6144 + 命令行 8192 → heap_size_limit 8240MB)。 顺带改准两处已经和事实对不上的注释: · 「观测峰值 6.03G,留 33% 余量」是分批改造**之前**的旧数,实测只用到 36%(2.8 倍余量); 写明以后调这个数必须重新量,别再拿 6.03G 当依据。 · 「与 8192 相等是刻意的过渡态」—— 过渡态已结束,改成说明为什么堆上限必须低于 mem_limit。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
luoqi committed