dsh_shenxian

0 Fork 0

Files

T

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

feat(models): 平台自建「模型设置」—— 用户自配厂家 / 条目各自开关 / 共享模型开关（档案 87）

2026-09-14 00:00:15 +08:00

初始提交：DSH 多租户平台（dshs）

2026-09-13 16:18:10 +08:00

nginx

初始提交：DSH 多租户平台（dshs）

2026-09-13 16:18:10 +08:00

supervisor

fix(mem): 内存口径定案 —— BASE 448 / MIN 448 / MAX 1024（用户裁定）

2026-09-14 21:38:57 +08:00

web