dsh web 内存持续泄漏：运行约 50 分钟 OOM 崩溃（附 4 处无界累积点定位）

[level0000x]

现象

dsh web 启动后 V8 堆内存持续增长，运行约 50 分钟触顶 4GB 后崩溃：

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

崩溃前 GC 日志显示堆在约 3024 秒内从 4.0GB 涨到 4067/4090 MB，Mark-Compact 单次耗时 3.1 秒，期间服务卡死无响应。症状是"运行久了越来越卡，最后没响应"。

版本：0.1.0-rc.5 与 0.1.1-rc.2 均可复现。
环境：Windows 11 x64，Node v26.3.0，pnpm 11.7.0。

复现步骤

1. 仓库根目录运行 pnpm dsh web
2. 浏览器打开 http://127.0.0.1:3080，保持页面长连接（SSE/WebSocket）
3. 进行 agent 对话活动
4. 观察进程内存持续增长，约 50 分钟崩溃（exit code 134）

定位

我们排查到 4 个无界累积点（均附代码证据）：

1. FrameQueue.buffer 无界队列（最严重）

packages/host/apiproxy/src/api-proxy.ts

class FrameQueue<F> {
  private buffer: F[] = []      // 无上限
  push(item: F): void {
    if (this.done) return
    this.buffer.push(item)      // 无条件入队，无背压/丢弃
    this.waiter?.()
  }

每个 mux/host 订阅者一个队列，每个 session/event 帧复制到每个订阅者队列一份。浏览器标签挂起/慢消费时（TCP 未断），帧无限堆积，每帧持有完整事件引用。

2. Session.log 事件日志无界

packages/core/session/src/index.ts — private log: SessionEvent[] = []，append-only 不裁剪。长时间 agent 会话事件永久驻留。

3. SessionProjectionCache 缓存行从不删除

packages/session/session-projection-cache/src/index.ts

this.ctx.on('session/disposed', (session: Session) => {
  this.markClean(session)
  this.dirty.delete(session)
  // 没有 table.delete(...) —— 投影缓存行不随 session 销毁删除
})

底层 KvTable（packages/storage/storage-domain/src/domain.ts）全量常驻内存 Map，行数随历史 session 数量无界增长。

4. SessionWriteBehind.pending 写失败无限保留

packages/session/session-persistence/src/write-behind.ts

this.pending = batch.concat(this.pending)   // 写失败后整批无限保留重试，无上限

每个事件还 structuredClone 一份。

建议修复方向

1. FrameQueue 加有界队列 + 背压/丢帧合并策略（或按 session/event 快照合并）
2. Session.log 提供裁剪/淘汰机制
3. session/disposed 时删除投影缓存行（或 LRU 上限）
4. write-behind 加重试上限/最大保留量

附带问题

• dsh web 无条件挂载 client-hmr（packages/bundle/web-app/cordis.patch.yml），每 500ms stat-poll 所有 client bundle。在无 dev:web watch 时也保持轮询，建议提供配置开关或调大默认间隔。

期待官方确认和修复，需要更多日志或 heap snapshot 我可以补充。

[level0000x]

让代理写的我只是直接复制过来声明

[o0lirvyi0o]

我也遇到同样的问题了，我是使用pi帮忙排查的，版本是@deepseek-ai/dsh@0.1.1-rc.2，看来要等明天看看是否修复

[level0000x]

反正就看什么时候修了

[level0000x]

反正就是好影响使用的说（最开始我还以为是自己的问题）

[7889545]

Cross-ref: #1550 (same family, cold-boot side) now has a controlled experiment showing that only physically moving session dirs out of sessions/ restores normal boot heap (~3 GB → ~306 MB), while archivedSessionIds and preparedSessionCacheSize are not materialization boundaries — plus source verification that the full-event structuredClone seed survives into 0.1.1-rc.2 (dsh-session-persistence lib/index.js:1389, verified by packing the npm tarball).

Your four accumulators (FrameQueue buffer, Session.log, projection cache, +1) look like additional unbounded growth points on top of the same design gap; since you reproduced on 0.1.1-rc.2, the two threads together suggest none of this shipped fixed yet. Linking them here so the boot-materialization and runtime-growth evidence stays findable from either thread.

（中文摘要:#1550 已实证仅移出 sessions 目录可恢复启动堆,且 rc.2 源码中 structuredClone seed 未变;你的四个无界累积点与冷启动全量物化同属一个设计缺口,互链存档。）

[yzke]

同类问题 +1，顶一下，希望官方早点修复。

环境：WSL2 (Linux)，@deepseek-ai/dsh 0.1.1-rc.2，Node v24.14.1，dsh web（systemd 服务）。

复现过程：

• 重启后正常使用，RSS 约 264 MB，约 6 小时后涨到 6.28 GB，UI 明显变卡。
• 单独压测只读 API：先 session.list，再逐个打开几个较大的历史会话（session.history），RSS 约 0.55 GB → 1.9 GB，只涨不自动回落。

排查结果：

• 5.5 GB RSS 时 V8 heap 仅约 170 MB、external 约 29 MB，匿名内存基本都在 glibc [heap]。
• gdb 抓大块 malloc 栈：ZSTD_decompressStream（node:zlib，约 2.5 MB/次）和 V8 JsonStringifier::Extend（约 0.5–1 MB/次），对应冷会话全量 zstd 解压/JSON 解析和高频全量 JSON 序列化。
• malloc_trim(0) 后同进程 RSS 5.48 GB → 549 MB，说明大部分是已释放但未归还 OS 的分配器高水位，叠加冷会话全量物化，不是单纯 JS 堆泄漏。

和本贴 #1550 的现象一致，辛苦官方优先处理。

[alpacachen]

每个 Token 都会形成 assistant/chunk 事件；
所有会话事件都会复制到每一个 mux 客户端；
慢客户端的队列没有上限、没有背压、没有合并；
多个子代理高频输出时，主 Node 事件循环承担全部序列化和广播；
队列积压后 shift() 又会产生二次 CPU 压力；
最终不仅 UI 卡，其他 Agent 的异步回调也会被同一个事件循环拖慢。
这不是只存在于你本机。官方仓库已经有同类报告：Discussion #3876，其中明确指出：

FrameQueue.buffer 无界；
Session 日志常驻内存；
投影缓存不淘汰；
写失败队列无限保留；
0.1.1-rc.2 仍能复现。
你当前安装的是 @deepseek-ai/dsh 0.1.0-rc.7；但仅升级到当前 0.1.1-rc.2 不能确认解决。

判断
目前的主次关系是：

主要直接原因：子代理没有跨根会话的公平并发限制，单个会话耗尽 Codex 并发。
放大器：所有 Agent 共用单 Node 进程和全局事件广播，无界 FrameQueue 会逐步拖垮事件循环。
当前 HTTP 探测仍正常，3081 的 P95 约 5.68ms，说明现在还没完全进入 Node/GC 卡死阶段；你此刻看到的长时间等待主要还是模型并发饥饿。
本机还有一个旧 DSH 进程运行在 3080，其辅助服务占用了 *:3081；当前 127.0.0.1:3081 实际由桌面版 PID 78081 响应，因此不是本次主因，但属于需要清理的端口重叠风险。

[LeoNardo-LB]

Linux 侧 +1：0.1.2-rc.1 仍复现（附活进程取证与 readRaw 单调用量化）

补充一个 Linux 数据点，与 @yzke 的 gdb 结论和 #1550 的冷启动实验完全对上，并给 readRaw 的单调用内存代价一个直接测量值。

环境

• @deepseek-ai/dsh 0.1.2-rc.1（linuxbrew 全局安装），Node v26.7.0，Linux x64（14 GB RAM，swap 长期占用高）
• dsh web --no-open 以 systemd --user 服务运行（Restart=on-failure, RestartSec=5）
• 工作区含多个大会话（最大 45 MB zstd / 128 MB 明文 / 17 万+事件量级），GUI 归档过 106 个会话

崩溃形态

重度使用（多会话并行）时段 20 分钟内 5 连崩，journal 全是 Main process exited, code=killed, status=6/ABRT；服务日志即经典 FATAL ERROR: Ineffective mark-compacts near heap limit，GC 日志显示堆 2040/2144 MB。systemd 5 秒拉起 → 所有进行中的 agent 会话被切断，用户必须手动"继续"。

活进程取证（inspector + smaps，与本帖结论互相印证）

对活进程做 HeapProfiler 采样 + /proc/<pid>/smaps 解析：

• 负载窗口（单个繁忙子代理会话 150 s）：RSS 430 MB → 1.16 GB，cgroup 峰值 3.8 GB、swap 1 GB；同期 V8 堆全程平稳（213→206 MB），JS 侧采样总分配仅 2.8 MB/150s → 增长几乎全在原生侧
• smaps：约 737 MB 落在 glibc [heap]（匿名私有），非 V8、非 arrayBuffers、非文件映射 —— 与 @yzke 抓到的 ZSTD_decompressStream / JsonStringifier::Extend malloc 栈一致
• 负载停止后 RSS 曾 1190 MB 自发回落到 390 MB —— 分配器高水位而非经典驻留泄漏，对应 @yzke 的 malloc_trim(0) 5.48 GB→549 MB 现象

readRaw 单调用直接量化

用最大的会话（45 MB zstd → 128 MB 明文）在隔离进程复刻 readRaw 的阶段开销：

阶段	RSS / external
起始	51 MB
全量明文	295 MB / ext 124 MB
逐帧拷贝（plaintexts 数组）	296 MB / ext 246 MB
Buffer.concat + toString("utf8")	647 MB / ext 483 MB

即一次 readRaw ≈ 647 MB 峰值，崩溃栈里的 v8::String::NewFromOneByte 正是最后的巨型 toString。工作区里同时物化 2~3 个这种会话即足以击穿 2.1 GB 上限 —— 与 #3275 "客户端一连上 60 s 内崩"是同一族。

结构确认：structuredClone 种子在 0.1.2-rc.1 未变

dsh-session-persistence lib/index.js:1390 与 :1586（seed: loaded.events.map((event) => structuredClone(event))）在当前发布版仍在，#1550 的冷启动全量物化路径未修。

缓解（与 #1550 的实验一致）+ 一个副作用数据点

1. 把 106 个 GUI 已归档会话目录（385 MB，含 45/36/35 MB 的大会话）物理移出 ~/.dsh/sessions/（保留 manifest 可回迁）→ 归档后剩余最大会话仅 5 MB，服务稳定。再次确认 archivedSessionIds 不是物化边界：归档态大会话仍留在盘上、仍可被加载触发全量物化。
2. systemd unit 加 NODE_OPTIONS=--max-old-space-size=4096。副作用数据点：提上限后 V8 GC 更"懒"，重启后 cgroup 峰值出现过一次 7.3 GB（旧 2 GB 上限时代是当场崩而不是冲峰）——在内存受限 + swap 紧张的机器上，这只是把崩溃换成高水位，不是治疗。

想请教维护者的

1. FrameQueue 有界化/背压（本帖第 1 点）有没有排期？
2. readRaw / 冷启动 seed 能否改流式或按需分段（配合 [Bug] Cold history loading fully materializes large/corrupt logs and can stall the entire Web server #1550 的结论，这可能是收益最大的一刀）？
3. 在修复落地前，官方是否考虑在文档里给出"大会话目录移出 sessions/"的正式指引？

（取证材料：堆快照/采样 profile/复刻脚本均有留存，需要可补充。）