会话累积后启动慢/内存高：projcache 全量载入与 session 列表全量扫描（0.2.1-rc.5 实测，附复现脚本与补丁建议）

[Scorpiolol]

TL;DR — 会话累积之后有两处 O(会话数) 的全量开销：(1) 宿主每次启动会把整个 session_projcache 全量读入内存并逐条校验；(2) 每次会话列表请求都会遍历整个 sessions 目录树、逐会话 open + 读 8 KiB 头并解压、再全量 stat，且当存在老格式日志时还会在同一请求里再走一遍树（historicalCorpusRevision 未记忆化）。
本机实测：4923 条投影记录 / 1011 MB → 读+JSON.parse 17.2 s、逐条 schema 校验 48.2 s；5975 个会话 → 单次 list() 约 7.8 s。两者都随会话数线性增长。本机历史崩溃日志里 5 次全部是 JavaScript heap out of memory。
不是来要求改的，只是把可复现的数据和最小补丁贴出来供参考。

English short version: After sessions accumulate, (1) every host boot eagerly loads the entire session_projcache domain (all record documents read + parsed + schema-validated; 4923 records / 1011 MB here → ~87 s of single-thread CPU, ~700 MB retained heap), and (2) every session-list request walks the whole tree, opens one log per session, reads its 8 KiB header, and stats every log (~7.8 s for 5975 sessions). A third walk is repeated on the same request when any log predates the current format, because historicalCorpusRevision() is not memoized. All three scale linearly with session count. Reproducer and a small patch below — posted as data, not as a demand.

环境

• macOS 26.6.2 / arm64 / 32 GB
• DSH Desktop 0.2.1-rc.5（npm latest）
• ~/.dsh/sessions ≈ 5975 个会话目录 / 5.2 GB（日志 5999 个，其中 4170 个是 v4 之前的老格式）
• ~/.dsh/storages/session_projcache 4923 条记录 / 1.0 GB

观察到的现象

1. 启动时单核打满数十秒（loadAll 是 open() 里的 await，会把宿主启动阻塞住）。
2. 常驻内存高：宿主进程 phys_footprint 2.4 GB / 峰值 3.3 GB，整机被拖进 swap。
3. 崩溃：~/Library/Logs/DeepSeek Harness/crash-*.log 里 5 次崩溃，全部是
   FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory，
   栈落在 node::fs::AfterOpenFileHandle → uv__work_done（异步 fs 回调），与上面第 1 条的全量读取吻合。
4. 打开/刷新会话列表时卡一下，会话越多越久。

三条机制（以 master 源码为准）

1）open() 内部 eager 全量 loadAll()

packages/storage/storage-domain/src/index.ts:119

const unit = await backend.kv.open(descriptorOf(spec))
const snapshot = await unit.loadAll()   // ← eager，阻塞 open()

KvUnit 接口只有 loadAll()，没有 lazy / paged / stream 的替代读法。session-projection-cache 在 Service.init 里无条件 storageDomain.open(spec)，于是每次宿主启动都会把整个 domain 拉进内存。

2）per-record 后端无界并发读

packages/storage/storage-json/src/per-record-unit.ts:166

const files = await readdir(dir, { withFileTypes: true })
const loaded = await Promise.all(files.map(async (file) => {   // ← 无并发上限
  ...
  const record = await readRecord(join(dir, file.name), versions)

上层 :87 还有一层对 table 目录的 Promise.all，两层相乘。每条记录都被 readFile 成字符串再 JSON.parse，随后由 domain 层逐条做 schema 校验；一次 fan-out 会在首条记录进入 records 之前持有整张表的瞬时副本。记录数随会话数增长，峰值内存也就随会话数增长。

3）会话列表全量扫描 + 语料 revision 未记忆化

packages/session/session-persistence-jsonl/src/index.ts

• listArtifacts()（:1138 起）：全树 readdir → 每个会话解析出一个 log generation → open() + 读 8192 B 头（:1499）→ zstd 解帧 → JSON.parse。
• list()（:522）：再对每个 artifact stat() 一次。
• historicalCorpusRevision()（:1121-1136）：每次调用都重新 listGenerations() 全树 walk + 对每个 log stat() + 对 [path, revision] 做 sha256，结果没有缓存。只要存在一个 sourceVersion < SESSION_FORMAT_VERSION 的日志（:531），每次 list() 都要多付这一整份。

本机 4170/5975 是老格式，所以这份税是每次列表请求都付的。

补充：list 路径一直是 pLimit(3) 有界的，这里的问题不是并发失控，而是总工作量 O(N) 被重复计算了一遍。

复现

脚本只读 ~/.dsh，不碰任何运行中的进程；在会话较多的机器上跑，数字会随会话数变化。

repro-dsh-session-scale.mjs

#!/usr/bin/env node
import { readdir, readFile, open, stat } from 'node:fs/promises'
import { join } from 'node:path'
import { homedir } from 'node:os'

const DSH = join(homedir(), '.dsh')
const now = () => performance.now()
const LOG_RE = /^session(?:\.v(\d+))?\.jsonl\.zstd$/

// [1] boot: storageDomain.open() → unit.loadAll() → readdir + readFile(all) + JSON.parse
async function projectionCacheLoad() {
  const dir = join(DSH, 'storages/session_projcache/sessions')
  let names
  try { names = (await readdir(dir)).filter((f) => f.endsWith('.json')) } catch { return }
  const t0 = now()
  let bytes = 0, parsed = 0
  await Promise.all(names.map(async (f) => {
    const text = await readFile(join(dir, f), 'utf8')
    bytes += text.length
    try { JSON.parse(text); parsed++ } catch {}
  }))
  console.log(`[boot/projcache] records=${names.length} size=${(bytes / 1048576).toFixed(1)}MB read+JSON.parse=${(now() - t0).toFixed(0)}ms`)
  console.log(`[boot/projcache] heapUsed after load ≈ ${(process.memoryUsage().heapUsed / 1048576).toFixed(0)}MB (schema validation adds more)`)
}

// [2] every list(): walk tree, open+read 8 KiB header per session, stat each log
async function sessionList() {
  const root = join(DSH, 'sessions')
  let wsEntries
  try { wsEntries = await readdir(root, { withFileTypes: true }) } catch { return }
  const t0 = now()
  let workspaces = 0, sessionDirs = 0, chosen = 0, opens = 0, bytes = 0, oldFormat = 0
  for (const ws of wsEntries) {
    if (!ws.isDirectory()) continue
    workspaces++
    for (const sd of await readdir(join(root, ws.name), { withFileTypes: true })) {
      if (!sd.isDirectory()) continue
      sessionDirs++
      const sdPath = join(root, ws.name, sd.name)
      let best = null, bestV = -1
      for (const f of await readdir(sdPath)) {
        const m = LOG_RE.exec(f)
        if (m === null) continue
        const v = m[1] === undefined ? 0 : Number(m[1])
        if (v >= bestV) { bestV = v; best = f }
      }
      if (best === null) continue
      chosen++
      if (bestV < 4) oldFormat++
      const p = join(sdPath, best)
      const fh = await open(p, 'r'); opens++
      const buf = Buffer.alloc(8192)
      const { bytesRead } = await fh.read(buf, 0, 8192, 0)
      await fh.close()
      bytes += bytesRead
      await stat(p)
    }
  }
  console.log(`[list] workspaces=${workspaces} sessionDirs=${sessionDirs} logsRead=${chosen} opens=${opens} headerBytes=${(bytes / 1048576).toFixed(1)}MB total=${(now() - t0).toFixed(0)}ms`)
  console.log(`[list] logs older than current format=${oldFormat} → triggers a second full tree walk + stat pass on this same request`)
}

await projectionCacheLoad()
await sessionList()

本机输出（脚本是串行的，真实代码 list 侧是 pLimit(3)，墙钟时间会不同）：

[boot/projcache] records=15 size=5.3MB read+JSON.parse=63ms        # 清空缓存后
[list] workspaces=36 sessionDirs=5975 logsRead=5975 opens=5975 headerBytes=46.5MB total=4529ms
[list] logs older than current format=4170 → triggers a second full tree walk + stat pass

清理前的实测数据

项	本机值
投影缓存记录数 / 体积	4923 / 1011 MB（中位数 105 KB，最大 4.2 MB）
open() 全量加载：读 + JSON.parse	17.2 s
同上 + 逐条 schema 校验	48.2 s（合计约 87 s 单线程 CPU；更高并发口径下独立复刻为 27 s）
加载后常驻 heapUsed	700 MB（更高并发口径 2279 MB，峰值 footprint 3.9 GB）
list()：open / readdir / stat 次数	5975 / 12002 / 11930
list() 单次墙钟	7.8 s
因老格式多付的一次 walk + stat	787 ms / 每次请求

缓存体量的构成（供参考，不是要指认谁）：context* 这组投影合计约占字节数的 92%（其中一部分由官方 dsh-token-meter 注册），单个 contextTimeline 就占 ~72–77%。也就是说这份派生缓存的大小主要由投影 payload 决定，而不只是会话条数——但无论 payload 多大，它都是被全量加载的，这才是问题所在。

为什么这不是个例

两项成本的分母都是「会话数 × 单条大小」与「会话数」。会话只增不减（见下），所以这是一个必然随时间触顶的形状：在本机约 5000 条会话时就已经到 2–3 GB 峰值堆，再翻一倍就会撞上 V8 的堆上限——这也正是崩溃日志里的 OOM。

想确认的问题

1. storageDomain.open() 里的 eager loadAll() 是有意的设计（比如为了在 open 后保证同步读一致），还是可以改成 lazy / paged / 按需？KvUnit 目前只有 loadAll() 一个读法。
2. session-persistence-jsonl 的 README 明确写了 "Nothing deletes session files" 与 "No eviction or retention surface"。这个「累积由外部维护」的立场是有意的吗？如果是，社区侧能安全依赖的手工清理姿势是什么（尤其投影缓存里的孤儿记录——删掉会话目录并不会让它消失，下次启动仍会被全量加载）。
3. historicalCorpusRevision() 的结果能否按 (log path, revision/size, mtime) 记忆化？看起来它是纯函数式的，只是每次重算。

附带一个最小补丁（供参考，不要求采纳）

把 loadTableRecords() 的无界 Promise.all 改成有界并发（默认 16），不改任何语义：结果顺序、Promise.all 的 rejection 行为、以及「单条坏记录读作缺失」都保持不变。

已用一个独立 harness 验证 26 项（16 项等价性 + 4 项并发上限 + 6 项 rejection 语义）：空表 / 单条 / 25 条 / 200 条 / falsy 与结构化值 / 坏记录读作缺失 / readdir 失败透传 / 实测 in-flight 由 64 降至 16 且小表不被串行化 / 首个拒绝胜出且无未处理 rejection。

0001-bounded-concurrency.patch

diff --git a/packages/storage/storage-json/src/per-record-unit.ts b/packages/storage/storage-json/src/per-record-unit.ts
index 3284f64a..192167b4 100644
--- a/packages/storage/storage-json/src/per-record-unit.ts
+++ b/packages/storage/storage-json/src/per-record-unit.ts
@@ -39,6 +39,14 @@ import type { UnitState } from './format.ts'
 /** Keys become path segments in this layout; this set is path-safe on every OS. */
 const SAFE_KEY_RE = /^[a-zA-Z0-9_-]+$/
 
+/**
+ * Maximum record documents {@link loadTableRecords} reads at once. Every read
+ * keeps one whole document in memory and parses it into a record, so an
+ * unbounded fan-out holds a transient copy of a whole table before the first
+ * record reaches `records`; this bound caps that transient cost.
+ */
+const RECORD_READ_CONCURRENCY = 16
+
 /**
  * Open one `per-record`-layout unit under `root`: the unit directory is
  * `<root>/<name>/`. Loads lazily on the first `loadAll` — this unit holds no
@@ -163,18 +171,46 @@ async function bootstrapLegacyUnit(descriptor: KvUnitDescriptor, dir: string, st
  */
 async function loadTableRecords(records: Map<string, unknown>, versions: readonly number[], dir: string): Promise<void> {
   const files = await readdir(dir, { withFileTypes: true })
-  const loaded = await Promise.all(files.map(async (file) => {
+  const loaded = await mapWithConcurrency(files, RECORD_READ_CONCURRENCY, async (file) => {
     if (!file.name.endsWith('.json')) return
     const key = file.name.slice(0, -'.json'.length)
     if (!SAFE_KEY_RE.test(key)) return
     const record = await readRecord(join(dir, file.name), versions)
     if (record !== undefined) return [key, record] as const
-  }))
+  })
   for (const record of loaded) {
     if (record !== undefined) records.set(...record)
   }
 }
 
+/**
+ * Run `task` over `items` with at most `limit` calls in flight. Results keep
+ * `items` order whatever the completion order; the first rejection rejects the
+ * call, as with `Promise.all`.
+ */
+async function mapWithConcurrency<T, R>(
+  items: readonly T[],
+  limit: number,
+  task: (item: T) => Promise<R>,
+): Promise<R[]> {
+  const results: R[] = []
+  const pending = items[Symbol.iterator]()
+  let position = 0
+  const worker = async (): Promise<void> => {
+    for (const item of pending) {
+      const index = position
+      position += 1
+      results[index] = await task(item)
+    }
+  }
+  await Promise.all(Array.from({ length: Math.min(limit, items.length) }, () => worker()))
+  return results
+}
+
 /** Read one record document; a foreign (unreadable or stale) one reads as absent. */
 async function readRecord(path: string, versions: readonly number[]): Promise<unknown> {
   try {

这一条只降低峰值内存、不减少总工作量；真正要解决启动耗时，还是得让 loadAll() 支持 lazy/paged。补丁里没有包含 historicalCorpusRevision 的记忆化——跨工作区/多 persistence 实例下的失效条件我没把握写对，宁可只报告不硬改。

如果这三条里哪一条其实是预期行为，还请直接说，我就不再往这个方向推了。感谢。