Generated by Answer me with HTML 0.5.7 · 2026-10-23 16:09 · ★ Star on GitHub

写入链路隔离测试结果

读取干净、写入是源头，且是一次性大跳

source隔离库实测 3 轮 · 生产库副本 · 2026-10-23

三条结论

读取链路完全干净：20 次真实命中召回只涨 1.2 MB。
写入链路是增长源，形态是一次性大跳 47 到 104 MB，之后每次 1 到 3 MB。
隔离环境稳态停在 178 到 236 MB，生产跑到 400 MB，差距在「写入次数累积」。
embed 缓存补丁只覆盖约 42 MB 上限，不是主因，这点我先前判断错了。

A

三次隔离复现

场景	冷启	首次 search	首次 add	稳态
全新建库	91 MB	—	+80 MB	178 MB
生产库副本 1942 条	92 MB	+38 MB	+47 MB	180 MB
生产库副本加 13 轮对话	93 MB	+38 MB	+104 MB	236 MB

数据

全新建库稳态	178MB
生产库副本稳态	180MB
加 13 轮对话稳态	236MB
生产真机 4 小时	392MB

三种场景的第一次成功写入都会跳一大截，之后每次只涨 1 到 3 MB。
生产库副本证明「库规模」本身不制造几百 MB，只影响首次预热幅度。
40 KB 与 80 KB 载荷的写入被上游拒绝，返回失败，所以载荷阶梯没测成。
隔离里都跑不起来的长载荷，恰是生产每次写入的真实形态。

B

读取侧对照

唯一查询十次后增量max 0 MB

真实命中召回二十次max 1.2 MB

单次读取平均增量max 0.06 MB

十次不同查询打在同一个进程上，RSS 一动不动。
二十次带真实命中的召回，从 393.0 只到 394.2 MB。
静置观察都不回落，说明是常驻不是延迟回收。
结论明确：不用再往读取和向量检索方向查。

C

生产与隔离的差距落在哪

生产写入次数: 10 次，4 小时
生产读取次数: 33 次
生产 RSS 轨迹: 91 → 157 → 391 → 415 → 392
隔离成功写入: 1 到 3 次
隔离稳态: 178 到 236 MB

生产每次写入带 6 轮真实对话，单次 workflow 约 19 秒。
隔离的合成载荷要么只有 5 KB，要么因轮数过多被拒。
所以差距最可能来自「长对话写入的单次代价」，而不是库变大。
写入过程会打一行 list_by_user found=1942，即每次全量拉 1942 条元数据。

D

三个可选动作

方案	做法	预期	代价
A 维持现状	阈值保持 450	工作点 400 不触发重启	常驻 400 MB
B 缩小写入	写入窗口 8 改 4 到 5	单次载荷变小，峰值下移	改 .env 加重启网关
C 改代码	减少写入期全量拉取	削掉规模相关固定开销	改 site-packages

A 零风险：现在就工作在这个水平，系统可用 525 MB，没到紧张线。
B 是我能量化验证的下一步，改完用同一套隔离探针复测即可。
C 收益最不确定，且要再改一处 site-packages，不值当先做。
网关那 43 MB 已经落地，不用再动。

E

当前状态

hy-memory: 392 MB，运行 4 小时
网关: 496 MB，运行 4.7 小时
系统可用: 525 MB
看门狗阈值: 450 MB，未触发

隔离库已清理，scratch 从 480 MB 回到 5 MB。
生产库全程没被写过，探针都打在副本上。 AM_EOF

---
template: sheet
theme: shadcn
title: 写入链路隔离测试结果
subtitle: 读取干净、写入是源头，且是一次性大跳
cols: 3
source: 隔离库实测 3 轮 · 生产库副本 · 2026-10-23
---

```callout warn 三条结论
- 读取链路完全干净：20 次真实命中召回只涨 1.2 MB。
- 写入链路是增长源，形态是一次性大跳 47 到 104 MB，之后每次 1 到 3 MB。
- 隔离环境稳态停在 178 到 236 MB，生产跑到 400 MB，差距在「写入次数累积」。
- embed 缓存补丁只覆盖约 42 MB 上限，不是主因，这点我先前判断错了。
```

## A 三次隔离复现

| 场景 | 冷启 | 首次 search | 首次 add | 稳态 |
|---|---|---|---|---|
| 全新建库 | 91 MB | — | ok +80 MB | 178 MB |
| 生产库副本 1942 条 | 92 MB | +38 MB | ok +47 MB | 180 MB |
| 生产库副本 加 13 轮对话 | 93 MB | +38 MB | ok +104 MB | 236 MB |

```chart bar unit=MB
全新建库 稳态 | 178
生产库副本 稳态 | 180
加 13 轮对话 稳态 | 236
生产真机 4 小时 | 392
```

- 三种场景的第一次成功写入都会跳一大截，之后每次只涨 1 到 3 MB。
- 生产库副本证明「库规模」本身不制造几百 MB，只影响首次预热幅度。
- 40 KB 与 80 KB 载荷的写入被上游拒绝，返回失败，所以载荷阶梯没测成。
- 隔离里都跑不起来的长载荷，恰是生产每次写入的真实形态。

## B 读取侧对照

```limits
唯一查询十次后增量 | 0 | MB
真实命中召回二十次 | 1.2 | MB
单次读取平均增量 | 0.06 | MB
```

- 十次不同查询打在同一个进程上，RSS 一动不动。
- 二十次带真实命中的召回，从 393.0 只到 394.2 MB。
- 静置观察都不回落，说明是常驻不是延迟回收。
- 结论明确：不用再往读取和向量检索方向查。

## C 生产与隔离的差距落在哪

```kv
生产写入次数: 10 次，4 小时
生产读取次数: 33 次
生产 RSS 轨迹: 91 → 157 → 391 → 415 → 392
隔离成功写入: 1 到 3 次
隔离稳态: 178 到 236 MB
```

- 生产每次写入带 6 轮真实对话，单次 workflow 约 19 秒。
- 隔离的合成载荷要么只有 5 KB，要么因轮数过多被拒。
- 所以差距最可能来自「长对话写入的单次代价」，而不是库变大。
- 写入过程会打一行 list_by_user found=1942，即每次全量拉 1942 条元数据。

## D 三个可选动作

| 方案 | 做法 | 预期 | 代价 |
|---|---|---|---|
| A 维持现状 | 阈值保持 450 | 工作点 400 不触发重启 | 常驻 400 MB |
| B 缩小写入 | 写入窗口 8 改 4 到 5 | 单次载荷变小，峰值下移 | 改 .env 加重启网关 |
| C 改代码 | 减少写入期全量拉取 | 削掉规模相关固定开销 | 改 site-packages |

- A 零风险：现在就工作在这个水平，系统可用 525 MB，没到紧张线。
- B 是我能量化验证的下一步，改完用同一套隔离探针复测即可。
- C 收益最不确定，且要再改一处 site-packages，不值当先做。
- 网关那 43 MB 已经落地，不用再动。

## E 当前状态

```kv
hy-memory: 392 MB，运行 4 小时
网关: 496 MB，运行 4.7 小时
系统可用: 525 MB
看门狗阈值: 450 MB，未触发
```

- 隔离库已清理，scratch 从 480 MB 回到 5 MB。
- 生产库全程没被写过，探针都打在副本上。
AM_EOF