加了 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>
| Name |
Last commit
|
Last update |
|---|---|---|
| .claude | Loading commit data... | |
| .design-sync | Loading commit data... | |
| apps | Loading commit data... | |
| clickhouse/config.d | Loading commit data... | |
| deploy | Loading commit data... | |
| docs | Loading commit data... | |
| packages | Loading commit data... | |
| scripts | Loading commit data... | |
| .gitignore | Loading commit data... | |
| .gitlab-ci.yml | Loading commit data... | |
| .npmrc | Loading commit data... | |
| .prettierrc | Loading commit data... | |
| README.md | Loading commit data... | |
| docker-compose.expose.yml | Loading commit data... | |
| docker-compose.managed.yml | Loading commit data... | |
| docker-compose.prod.yml | Loading commit data... | |
| docker-compose.yml | Loading commit data... | |
| eslint.config.mjs | Loading commit data... | |
| liu.cjs | Loading commit data... | |
| package.json | Loading commit data... | |
| pnpm-lock.yaml | Loading commit data... | |
| pnpm-workspace.yaml | Loading commit data... | |
| tsconfig.base.json | Loading commit data... | |
| turbo.json | Loading commit data... |