 admin
|
683c4cdeff
|
fix(mem): 内存口径定案 —— BASE 448 / MIN 448 / MAX 1024（用户裁定）
用户裁定：「base 448 没问题 max 就是 1024」。据此把两侧常量收成一份事实
（编排器 instanceMemMb() 与插件客户端 MEM_* 必须逐值一致，verify-mem-model 会守着）：
· BASE 160 → 448：0.1.5 基座**实测 312 MiB**，旧值按 0.1.2 的 106~145 估的、严重低估
⇒ 384 的上限里只剩 72 MiB 给插件，这正是宿主 swap 被吃掉（452 MiB）的原因
· MIN 384 → 448：**MIN 必须 ≥ BASE**，否则 clamp(raw, MIN, MAX) 的下限失去意义
（旧 384 在 BASE=160 时满足该不变量，抬 BASE 后必须跟着抬）
· MAX 1536 → 1024：不是偏好，而是编排器头部既有的不变量
「上限 1024M 是单实例硬顶（宿主 1870M）」；在途草稿的 1536 与宿主容量前提自相矛盾
· mcn 成本表保持 128（驳回草稿的 256）：无可支撑抬高的实测，反向有证据 ——
装了它的用户在旧 384 上限下一直跑得住 ⇒ 需求 ≤384；而抬高会直接吃宿主余量
实测（铺发+重启后经 /api/dsh/status 核对）：admin 384→576、guest 384→448，
均在 [448,1024] 内；heapMb 256；两实例 restarts:0。宿主可用 761→1267 MiB。
本机 verify-mem-model 与 npm run verify 均**首次全绿**。
插件 business-plugins 0.3.16 → 0.3.17（客户端常量随之更新）。
|
2026-09-14 21:38:57 +08:00 |
|
|
admin
|
f6d4ad9b15
|
fix(mem): 统一实例内存配额口径 + status 暴露真值（消灭「388 MiB」误报）
用户问「实例内存大小是不是调整过了，为什么功能设置中还是显示 388 多」。
实测：guest 真实 MemoryMax = 672 MiB、admin = 384 MiB（都真调整过）；
而「功能管理」显示的是插件**自建的第二套模型**（基线 285 / univer 64 / mcn 39，
且把 clamp 下限 384 当硬上限）⇒ 全勾显示 388 并报「⚠ 将超出上限」，纯误报。
根因：档案 81 R1 把「写死 384」改为「按插件集合推导」时**只改了编排器**，
插件那份副本原地漂移，此后 univer 384→512、mcn-suite 128 都没同步。
平台侧（把已算好的真值透出来，零新增计算）：
- spawner.ts 新增可选 quotaInfo?(userId)（照 breakerInfo 模式）
- orchestrator.ts 实现 quotaInfo()，走**同一个** instanceMemMb()/heapMbFor()
- /api/dsh/status 返回 quota: {memMb, heapMb}
防漂（根因是「同一事实两处副本」，必须让它不可能再漂）：
- 新增 scripts/verify-mem-model.mjs，逐项交叉断言常量/成本表/clamp 算式/接线点，
接进 npm run verify —— 任一处漂移即构建失败（已做反向验证：改回 285 即 exit 1）
验证：build 零报错；verify 全绿（含新增 15 项断言）；服务端 md5 与本机编译产物一致；
GET /api/dsh/status → quota {memMb:384,heapMb:256} 与实测 402653184 吻合。
注：poc/business-plugins/**（0.3.6）与其 package.json 未在此提交 —— 该文件被并行会话
连续改过两轮（0.3.4/0.3.5，0.3.5 已上线但未 commit），刻意留给他们一起提交。
|
2026-09-13 21:38:04 +08:00 |
|