[bug反馈] 超长会话因流式增量碎片（reasoning-chunks / text-chunks）未自动清理导致内存溢出 (OOM) 与历史加载失败

[zlinwzx147258]

1. 问题背景与现象描述

在长轮次会话（如 500+ 轮，使用深度思考模型并伴随大量工具调用的复杂工程任务）中，dsh Web 服务端在尝试加载该会话历史时，
会持续报错 历史加载失败：Failed to fetch（internal），后端进程频繁因 V8 堆内存溢出崩溃。

排查发现，会话持久化归档（session.jsonl.zstd）中堆积了海量的单字流式增量事件（reasoning-chunks、text-chunks、
assistant/chunk 等）。这些流式增量分片在生成阶段用于前端实时打字机动效，但在单轮对话结束后仍永久保留在追加日志
（append-only log）中。

当单会话的增量事件累积到数百万条时，打开会话会触发严重问题：

1. Node.js V8 堆内存耗尽：全量反序列化数百万个细碎 JSON 对象，瞬间突破 --max-old-space-size=4096 限制导致 OOM 崩溃。

2. GC 全停顿（Stop-the-World）引发超时：V8 管理数百万微小对象时垃圾回收停顿长达数秒甚至数十秒，导致前端 RPC/HTTP 请求
   超时（Failed to fetch）。

3. 前端浏览器崩溃：直接传输全量数据会导致浏览器标签页内存暴涨甚至白屏闪退。

———

2. 根因分析

• 流式分片无界膨胀且未在落盘后固化清理：每次大模型吐出的单字 delta 都会写入 session.jsonl。在一个 636 轮的真实会话中，
  累计产生了 826 万条流式分片记录（压缩包达 107MB，解压后纯文本接近 1GB）。

• 数据冗余与生命周期错位：当一轮对话结束时，所有思考链文本、最终回答及工具调用参数已完整合并并固化在最终的 assistant/
  message 语义事件中（data.message.content 下完整保留了 reasoning 和 tool-call 节点）。中间产生的流式增量已无业务价
  值，却仍常驻日志。

• 加载器缺乏惰性分页与投影机制：服务端在打开会话时一次性将全部事件反序列化进内存，而非按需加载或仅读取语义节点。

———

3. 实测数据对比（以会话 session-db1773c0-7501-4bc9-a48c-0ee2acd0d122 为例）

📉 存储与资源开销

• 流式打字增量记录：8,260,000+ 条 ➔ 0 条（无用碎片清理率 100%）
• Zstandard 归档体积：107 MB ➔ 13 MB（体积缩减 88%）
• 内存占用与加载表现：全量反序列化崩溃（>4GB OOM） ➔ 毫秒级秒开（<300MB RSS，运行平稳）

🛡️ 业务数据完整性验证（100% 无损保留）

• 真实业务事件：保留 52,596 条（含全部用户输入、工具执行调用及系统事件）
• Assistant 消息：保留 9,283 条完整响应
• 深度思考（Reasoning）：保留 8,025 处完整思考链（单块思考链最长达 1.7 万字）
• 内核投影校验：foldSurface（836 个状态节点）与 TokenMeter 校验 全部通过，0 报错
  注：经内核 foldSurface 与 TokenMeter 投影校验，会话中包含的 636 轮用户输入、最长达 1.7 万字的思考链、所有工具调用与执
  行输出 100% 无损保留。

———

4. 优化建议

1. 会话轮次结束时自动执行增量清理（Auto Compaction）：

   • 在 turn/end 或持久化落盘时增加钩子：当父级 assistant/message 完成锚点已成功组装并写入磁盘后，自动剪除对应的临时
     流式分片（*-chunks、assistant/chunk）。

2. 提供官方离线会话压缩与修复 CLI：

   • 增加内置命令（如 dsh session compact ），支持：
     • 剔除历史会话中的临时分片；
     • 重新紧凑连续编号 seq；
     • 联动重映射 sourceEventSeqs、surfaceOp 以及 compaction/prune / compaction/summary 中的 shadowedRange，确保通
       过断言校验。

3. Web 端流式分页加载：

   • 优化 Web 后端加载逻辑，避免打开会话时一次性全量反序列化整个历史。

———

5. 复现环境信息

• 操作系统：Linux x86_64 (Ubuntu 24.04 LTS / Kernel 6.8)
• 运行环境：Node.js v24.18.0
• 软件版本：@deepseek-ai/dsh (latest main build)
• 测试模型：deepseek-v4-pro / deepseek-v4-flash（带深度思考及多步骤工具调用模式）

[skywolf123]

是的，OOM严重，现在都只能开着NODE_OPTIONS="--max-old-space-size=4096"用，还很担心，node进程内存经常彪到4G。
特别是新版本0.1.2-rc.1

[xesable-ai]

实测补充：读侧物理删除 chunk 碎片不可行（会被稠密 seq + fold 连续性校验挡住），修复需落在写入端

感谢这个分析，我这边在 macOS 桌面上复现了同类 OOM，并顺着你的思路做了一次"读侧删碎片"的实测，结论是这条路走不通，希望能帮到修复方向的定位。

一、我这边观察到的 OOM（与你的现象一致）

• 环境：Oh-DSH Desktop 0.2.0 / @deepseek-ai/dsh 0.1.2-alpha.3 / 内置 node v26.0.0 / macOS 26.6.2 / 24 GB RAM
• 两次同签名崩溃（~/Library/Logs/DiagnosticReports/node-*.ips 均为 EXC_CRASH / SIGABRT，栈顶 node::OOMErrorHandler）：
  • 09-10 22:13，运行时已存活 18h51m
  • 09-12 23:38，运行时已存活 8h34m（间隔在缩短）
• ~/.ohdsh/logs/desktop.log 原文：

  Mark-Compact (reduce) 4062.1 (4099.0) -> 4062.1 (4097.8) MB ... last resort
    average mu = 0.127, current mu = 0.000
  FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
  DSH runtime exited: code=null signal=SIGABRT
  

  mu ≈ 0.1 → 0.000 说明回收几乎无效、存活对象就顶到 4 GB（V8 默认 old-space 上限），随后 runtime 被 abort、桌面自动重启。

二、碎片规模：存储行数被放大 3 个数量级

用官方 codec 展开（decodeStorageRecord），单个会话的"存储行 → 内存事件"倍率如下：

会话	存储行数	展开后事件数	其中 chunk 碎片	语义事件
A	9,137	151,395	149,875 (99%)	1,520
B	44,952	1,319,041	1,303,667 (99%)	15,374
C	48,607	1,705,740	1,687,983 (99%)	17,757
D	85,176	2,465,262	2,443,738 (99%)	21,524

即：打开一个大会话 = 堆里造出 130 万 ~ 246 万个细碎对象，与你说的"数百万个细碎 JSON 对象"量级吻合。
（旁证：崩溃重启后 1 分钟内，桌面立刻物化了某个 8.1 MB 会话的投影缓存。）

三、实测：读侧删除碎片不可行

方法（只读，未改动任何文件）：用官方原语 decodeStorageRecord 载入全部事件 → 用 decodeSeqRanges
把 sourceEventSeqs 的 [start,end] 存储形式展开 → 分别对"原始事件流"和"删除全部 chunk 事件后的事件流"
运行官方 foldSurface，对比结果。

结果：

事件总数: 151,395  |  碎片: 149,875 (99%)  |  语义: 1,520
基线（原始日志）         → ✅ 折叠成功: 节点 544
去碎片后（seq 出现空洞）  → ❌ 抛错: session event seq 278 is not contiguous; expected 15
原始日志自身空洞数: 0    ← seq 空间是稠密的

原因（都是设计上的硬约束）：

1. 会话日志的 seq 是稠密递增的（本例 0…151,394 零空洞）。
2. foldSurface 强制校验 seq 连续性与 sourceEventSeqs 引用完整性（源码注释："@throws when an event violates surface metadata, source-event references, range, or tool-result rewrite rules"）。
3. surface 是派生历史的唯一来源（"不存在原始日志回退"）→ seq 一有空洞，历史折叠直接失败，会话打不开。
4. 持久化明确不提供格式或压缩迁移（"不提供格式或压缩迁移、混合根回退或双写"）。

所以"事后清理 append-only 日志"这条路，会被 seq 稠密性 + 折叠校验这两道不变量挡住；要绕过就得重编号整个
seq 空间并改写所有引用与 header 血缘，属于格式级改写，风险远大于收益。

四、由此建议的修复方向（写入端，而非读侧）

1. 写入端不落盘临时 delta：在一轮结束、父级 assistant/message 锚点落盘后，让 assistant/chunk delta
   不再写入日志（或写入但不分配 seq，放到旁路/可裁剪存储）。这样 seq 仍保持稠密，读侧无需任何改动。
   —— 这也是你原帖"轮次结束时自动增量清理"的可行形态：清理必须发生在分配 seq 之前。
2. 或者反过来，让 foldSurface/loader 容忍 seq 空洞：把 *-chunks/assistant/chunk 显式标记为
   "不参与 surface 折叠"的类型，读侧就能安全裁剪历史日志。
3. 或者提供官方的日志压缩/迁移工具（当前明确不提供），让瘦身成为受支持操作而不是用户脚本。
4. 短期缓解（我们这边的现状）：把 V8 old-space 上限从 4 GB 提到 8 GB + 定期重启运行时；
   但这只是推迟崩溃，不解决增长本身。

如果需要，我可以提供复现脚本与脱敏后的日志样本（desktop.log 片段、.ips 摘要、以及上面这张展开倍率表）。

---

备注：以上数据来自一台使用中的机器（1,117 个会话、其中 14 个 >4 MB），会话内容未上传，仅提供统计口径与错误信息。