[Bug] 0.2.0-rc.2：dsh web 的 JS 主线程常驻 1 核、进程 2.35 核 —— 会话冷读 + 投影缓存 + describe 无缓存（含线程级取证）

[l429609201]

修订版原贴：删除线 处是原贴说错的，紧随其后的引用块给出更正。

EN TL;DR — On @deepseek-ai/dsh 0.2.0-rc.2 (dsh web, 36 vCPU / 16 GB, Node v22.23.3), one node process pinned 0.99 core of JS main thread (1.61–2.35 cores total), heap peak 13.3 GB, twice killed by SIGTERM timeout. Traced to main-thread hot paths: (1) the mobile App's /m/api/sessions folding session titles by cold-reading the whole 389 MB corpus (zstd decode + per-line JSON.parse, 8.9k–37k/s), amplified by its 7–9 s polling and by the cold-observation cache being hardcoded to 5 defaulting to 5 but configurable (preparedSessionCacheSize); (2) a plugin's projection cache wiped every pass (cap 256 < 269 files); (3) settings.describe() with no result cache. Local patches + preparedSessionCacheSize=384 cut it to 0.12–0.24 cores (~12×).

---

1. 环境

项	值
DSH / 运行时	@deepseek-ai/dsh 0.2.0-rc.2；Node v22.23.3；Ubuntu 24.04.5 LTS
硬件 / 部署	36 vCPU / 16 GB；单进程 dsh web（profile web，16 插件，--max-old-space-size=8192）
语料	~/.dsh/sessions/ 269 个 zstd 日志 / 389.1 MB；投影缓存 269 个 JSON
移动端	配套 Flutter App（Android），本体在 dsh-mobile-remote 仓库，经 /m/api/* 接入
涉及插件（均为第三方）	dsh-mobile-remote v3.1.5 ／ dsh-api-dashboard v1.6.9 ／ @linxin666/dsh-usage v0.4.4
版本说明	我实测于 0.2.0-rc.2；reviewer 复核 master = d7432673（v0.2.1-alpha.2），下述 (a)–(d) 均存在
已做调整	preparedSessionCacheSize 由默认 5 调到 384（≥ 269 个会话）

2. 症状

• 一个 node 进程长期占满 1 个核的 JS 主线程（0.99 核），进程合计 1.61–2.35 核；36 核机器上 load 仅 ~1.7。
• 4 个 V8 GC 线程合计 1.3 核常亮；RSS 2.9–4.6 GB、峰值 13.3 GB；两次 stop-sigterm timed out → SIGKILL。

3. 取证方法（全部只读）

线程级 /proc/<pid>/task/*/stat 双采样差分 · SIGUSR1 + CDP Profiler 采 V8 profile · 全局 JSON.parse 打点（次数/字节/调用者）· CDP 永假条件断点计数 · process._getActiveHandles() 挂临时 request 监听。

引用口径：下文用源码路径。原贴引的 dsh-*/lib/index.js:行
更正：那是构建产物行号，master 上不存在这些文件，行号不可平移。

4. 热点 1：会话日志冷读全量解压 + 逐行 JSON.parse 跑在主线程

实测 JSON.parse 峰值 37,000 次/秒，链路（两次独立采样一致）：
JSON.parse ← SessionLogScanner.consumeEventLine ← readZstdPrefix ← decodeStoredLog ← readColdSessionLog ← SessionCorpus.projectMany ← dsh-mobile-remote 的 GET /m/api/sessions。
触发方是该插件自带的 App：7–9 秒轮询一次，而一轮折叠要几十秒 ⇒ 请求自我叠加。

• (a) 冷读缓存容量硬编码 5、不可配置；实例化处只传并发度

更正：preparedSessionCacheSize 是公开配置项，默认 5（session-query/src/config.ts:12、src/index.ts:122-131，sqlite 后端同项，两份 README 都有配置表），实例化时并发度与缓存容量都传了。正确说法是：默认值太小，应按 ≥ 会话数配置（本机已配 384）。这条我记错了，撤回。

• (b) 会话 header 无 title、标题只能折叠日志 —— 属实。

补充：比"给 header 加字段"更省的是走内核已有的同步零 I/O 读面 cachedSnapshot(meta, keys?)（session-projection-cache/README.md:61）。我本地按此改，269 次标题读取中 264 次零 I/O 命中，不再解压日志。

• (c) 解码在主线程、只靠 scheduler.yield() 让出，worker 基建只用于校验 —— 属实。

补充：搬进 worker 还要对齐内核「worker 自然退出且 exit code 0 才算成功」的既有语义（session-persistence-jsonl/README.md:86），不是换个执行位置那么简单。

5. 热点 2：投影缓存每轮被整体清空（第三方插件，现场观测）

实测 loadCacheEntry 21.45 MB/秒（102.6 文件/秒）。直接原因是 dsh-api-dashboard v1.6.9 的 TTL 3s + if (size > 256) clear()，而本机有 269 个投影缓存文件 ⇒ 命中率恒为 0。

• 同步 view() 契约迫使插件同步读缓存文件

更正：契约确实是同步的（session-projection/src/index.ts:44-46），但内核已提供同步零 I/O 的 cachedSnapshot() ⇒ 「只能同步读文件」不成立，是消费方选错了读面（插件问题）。

6. 热点 3：settings.describe() 无结果缓存

实测 Function.toJSON 885 次/秒（网页轮询 /api/dsh-usage/overview → readNamespace → describe）。内核 settings/src/index.ts:302 无 ns 过滤、:304 每次 flatMap 全部 entry、:313-315 只记 revision 不缓存 descriptor、:391 内核自己也全量 describe().find()。

建议：:311 已经算出的 raw 签名正好当 descriptor 缓存键，同时加 describe({ ns })，并让 :391 的内部查询走同一缓存。（我本地只做了外围缓解：2 秒 TTL + 写后清缓存，承认不是正解。）

7. 本地修复与实测（第三方插件部分为现场观测）

对象	做法	结果
dsh-mobile-remote	标题折叠移出请求路径（后台单飞 + 缓存）；改用内核 cachedSnapshot() 零 I/O 读面	单测 24/24；264/269 次读取零 I/O
dsh-api-dashboard v1.6.9	上限 256→4096（按插入序淘汰）+ TTL 3s→30s + mtime/size 校验	双向验证 300 命中 / 原版塌成 43；21.45 → 0.01 MB/s
@linxin666/dsh-usage v0.4.4	readNamespace 加 60 秒 TTL	单测 8/8
内核配置	session-query-sqlite：preparedSessionCacheSize: 384	重启后连续 3 次会话列表：5.90s → 0.13s；稳态 RSS 2.09 GB

指标	修复前	修复后
JS 主线程	0.99 核	0.12–0.13 核
4 个 GC 线程	0.74–1.64 核	0.01–0.11 核
进程合计	1.61–2.35 核	0.13–0.24 核（≈12×）
RSS / 峰值	4.4 GB / 13.3 GB	~2.1 GB

8. 建议（按 reviewer 的优先级重排）

立即可用（部署侧）：① preparedSessionCacheSize 配到 ≥ 会话数；② 让 App 停止 7–9 秒轮询 /m/api/sessions（或仅列表可见时轮询）。

内核侧：① 给 header 加 title

更正：更省的是提供一条走 cachedSnapshot() 的 listSessionTitles() 同步零 I/O 接口。

② describe({ ns }) + 用 raw 当 descriptor 缓存键（含 :391 内部查询）；③ 冷读解码搬进 worker（注意 §4(c) 的退出语义）。

9. 复现思路

① 造 > 256 个会话（每个几十 MB）使投影缓存文件数超上限；② 打开 App（秒级轮询）或让网页端持续触发投影重算；③ /proc/<pid>/task/*/stat 双采样差分可见主线程接近 1 核、GC 线程合计 > 1 核，配合 JSON.parse 打点可见 MB/s 级解析量与调用者。

---

致谢

修订时间：2026-10-13

感谢 @PerryLink 逐条核对并给出源码位置。其中 (a) 是我记错的事实 —— 若不更正，整篇报告的第一条诉求会被一句"它是配置项"挡回；他顺手给的两处更省改法我也已采纳。

按他的意见做的改动

1. preparedSessionCacheSize 由默认 5 配到 384（≥ 本机 269 个会话）—— 是公开配置项，不是硬编码；
2. 标题读取改走内核已有的同步零 I/O 读面 cachedSnapshot() → 实测 264/269 次零 I/O；
3. 内核侧建议改为"提供走 cachedSnapshot() 的 listSessionTitles()"，不再提"给 header 加字段"；
4. worker 化那条补上「自然退出 + exit code 0」的语义边界；
5. 引用一律改源码路径（原先引的是构建产物行号）。

[PerryLink]

你引的三处结构性观察里 (b)(c)(d) 都扎实，但 (a) 有一条决定性的事实错误 —— 那个缓存容量是可配置的，而且在你自己的 0.2.0-rc.2 上就可配。先把这条改掉，否则整篇报告的第一个诉求会被一句"它是配置项"挡回。

1. ⚠️ (a) 不成立：preparedSessionCacheSize 是公开配置项

• packages/session-query/session-query/src/config.ts:12 → export const SESSION_QUERY_DEFAULT_PREPARED_SESSION_CACHE_SIZE = 5
• :20-25 → /** Maximum cold prepared-Session observations retained for reuse, keyed by durable revision. … Defaults to 5. */ preparedSessionCacheSize?: number
• packages/session-query/session-query/src/index.ts:122-131 → const preparedSessionCacheSize = config.preparedSessionCacheSize ?? SESSION_QUERY_DEFAULT_PREPARED_SESSION_CACHE_SIZE … this._observations = new SessionObservationReader(ctx, preparedSessionCacheSize)
• SQLite 后端同项：session-query-sqlite/src/index.ts:219-223 → preparedSessionCacheSize: z.number().step(1).min(1).max(Number.MAX_SAFE_INTEGER).default(SESSION_QUERY_DEFAULT_PREPARED_SESSION_CACHE_SIZE)
• 两份 README 的配置表都有它：session-query/README.md:61 → | preparedSessionCacheSize | 5 | Cold prepared-Session observations retained for reuse across observeSession reads |；session-query-sqlite/README.md:53 同

而且在 rc.2 上就已可配：dsh-v0.2.0-rc.2 的 …/session-query/src/config.ts:25、…/src/index.ts:131、…/session-query-sqlite/README.md:53 全部存在。

⇒ 所以「硬编码 5、不可配置」这个判断要撤掉。另外「实例化处只传并发度」也错：session-query/src/index.ts:130-131 同时传了并发度（给 SessionCorpus）与缓存容量（给 SessionObservationReader）。

正确表述：默认值是 5（SESSION_QUERY_DEFAULT_PREPARED_SESSION_CACHE_SIZE），可调；你的场景应把它配到 ≥ 会话数。

2. ✅ (b) header 无 title —— 属实，且是根因

packages/session/session-persistence-jsonl/src/format.ts:83-94：

interface HeaderLine { type: 'session'; version: number; id: SessionId; createdAt: number;
  cwd?: string; parentSession?: SessionId; isSeeded: boolean; origin?: 'subagent';
  delegationDepth: number; agentPreset?: string }

:96 HEADER_REQUIRED_KEYS = ['type','version','id','createdAt','isSeeded','delegationDepth']；:97 HEADER_OPTIONAL_KEYS = ['cwd','parentSession','origin','agentPreset'] ⇒ 确实没有 title（你列的 9 个键与之一致，只漏了判别字段 type）。标题是独立事件（session/title）。

⭐ 但"加字段"不是最省的改法 —— 内核已有一个同步零 I/O 的读面：

packages/session/session-projection-cache/README.md:61：

cachedSnapshot(meta, keys?) is the read-only face: it synchronously serves client values from the storage domain's in-memory tables with zero I/O.

⇒ 所以给消费方一条走 cachedSnapshot 的 listSessionTitles() 比改 header 格式更轻（后者是格式变更）。

3. ✅ (c) 主线程协作式解码 —— 属实，但请注意现有边界

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

• :946 private async readZstdPrefix(
• :962 let yieldDeadline = performance.now() + ZSTD_DECODE_YIELD_INTERVAL_MS
• :978-982 → if (remainingFrames > 0 && performance.now() >= yieldDeadline) { await scheduler.yield(); signal?.throwIfAborted(); yieldDeadline = performance.now() + ZSTD_DECODE_YIELD_INTERVAL_MS }

⇒ 确实在主线程，只靠 scheduler.yield() 让出。

worker 基建存在但只服务校验：:667 verifyCurrentFile: verifyCurrentGenerationInWorker；migration-verifier.ts:77 entry: new URL('./worker.cjs', import.meta.url)、:140 const worker = new Worker(entry, options)（git grep -n "new Worker" …/src/ → 仅此 1 处）。

⚠️ 搬进 worker 时要对齐内核现有的「Worker 自然退出且 exit code 0 才算成功」语义（README.md:86）—— 不是简单换个执行位置。

4. ✅ (d) describe() 无缓存、不能按 ns 过滤 —— 属实，且改法很容易

packages/settings/settings/src/index.ts：

• :302 describe(options?: SettingsDescribeOptions): SettingsDescriptor[] { —— 无 ns 入参
• :304 const descriptors = this.ownerContext.configEditor.configuration().flatMap(({ entry, inherited, override }) => {
• :311 const raw = JSON.stringify([entry.fiber.uid, schema.toJSON(), entry.options.config ?? {}])
• :313-315 ⇒ revisions 只记 revision，不缓存 descriptor
• :391 const descriptor = this.describe().find(row => row.ns === ns) —— 内核自己也全量取回再 find
• :422 this.describe() —— 每次 write 再来一遍

⇒ :311 已经算出了 raw 签名，正好可以当 descriptor 的缓存键。建议照这个提：

用 :311 已有的 raw 做 descriptor 缓存；同时给 describe 加 ns 过滤，并把 :391 的内部 describe().find() 接到同一缓存上。

5. ⚠️ 一处归因要收窄

你写"sync view() 契约迫使插件同步读缓存文件" —— 契约确实是同步的（packages/session/session-projection/src/index.ts:44-46：All functions MUST be synchronous (an async unit would tear the carriers' consistency cut)），但内核已提供同步零 I/O 的 cachedSnapshot() ⇒ 「只能同步读文件」这个理由不成立。

6. ⚠️ 与既有公开事实的关系（这条别写错）

内核已经测量并公开承认「成本正比于会话数」，所以那不是新发现：

• packages/session/session-persistence-jsonl/README.md:90 → Historical stat and list revisions require metadata work proportional to the root's Session count. … Current V4 body reads and revisions avoid the historical corpus scan.
• .agents/notes/implemented/architecture/2026-08-31-released-session-format-migrations.md#catalog-scan-measurements 的实测表（0/100/1000 无关会话）：stat 5.17/29.44/84.14 ms、cold read 19.00/77.48/237.97 ms，并自注「filesystem-cache-warm observations … not disk-cold latency or a performance gate」

⚠️ 但那条 note 量化的是「历史格式迁移扫描」；你的 381 MB 语料走的是当前格式冷读（readZstdPrefix 主线程逐行 parse）。成本同形，但不是同一条路径 —— 建议在报告里把两者分开说，并明确你的新增量在于「调用点在热路径 + 被 App 7–9 s 轮询放大」，而不是"发现成本随语料增长"。

7. 三个第三方插件热点

dsh-mobile-remote 的轮询、dsh-api-dashboard 的 >256 → clear()、@linxin666/dsh-usage —— 都不在本仓库，我无法核实，所以回答里不替它们下结论。建议你把这部分标为"现场观测"。

8. 建议的诉求重排（按收益）

1. 立即可用（你自己就能做）：把 preparedSessionCacheSize 配到 ≥ 会话数；并让移动端 App 停止 7–9 s 轮询 /m/api/sessions（或只在列表可见时轮询）。
2. 内核侧值得做：① header 增 title，或提供走 cachedSnapshot 的 listSessionTitles()；② describe({ ns }) + 用 :311 的 raw 做 descriptor 缓存；③ 把冷读解码搬进 worker_threads（注意第 3 节那条语义）。

9. 版本

你写 0.2.0-rc.2。我核的是 origin/master = d743267388（= dsh-v0.2.1-alpha.2），(a)–(d) 四处都在 master 上。⚠️ 另外提醒：你引的 dsh-*/lib/index.js:* 都是构建产物行号，master 上不存在这些文件 —— 行号不能平移，建议换成上面的源码位置。

[whengu]

都用nodejs技术栈了 , 性能问题就别管了吧, 反正nodejs的性能死活也好不到哪里去