【向量检索引擎】生产排障：召回、延迟、堆积、OOM

排障时最容易犯的错：把一切归因于 ef / nprobe。本系列前 16 篇给出的机制说明，真实故障往往落在 可见性、段状态、过滤选择度、离线队列、对象存储与副本拓扑。本文提供检查清单，不含未跑的集群数字。

本文是「向量检索引擎」系列第 17 篇（共 18 篇）。→ 系列目录

一、先分清四种「不好」

二、召回：对照金标准

1. 同一度量与归一化：cosine/IP/L2 与入库预处理是否一致（frontier/08、第 2 篇）。
2. Flat 金标准：小样本上 Flat/IDMAP 算 Recall@k，再比 HNSW/IVF（第 2、8 篇）。
3. 过滤：估选择度 \(s\)；低 \(s\) 时检查是否滤空局部 Top-\(k\)（第 11 篇）。
4. 删除/TTL：结果是否应排除已删/过期实体（第 13 篇）；bitset 是否传播到历史副本。
5. 索引就绪：Sealed 是否已建索并 handoff 到 Query Node（第 3、10 篇）——「能搜」可能走劣路径。

不要用「感觉答案不对」代替 Recall@k 与固定评测集。

三、延迟：拆等待 vs 计算 vs I/O

总延迟 ≈ 一致性等待 + 段加载/对象 GET + Growing/Sealed 检索 + 多级 reduce + 客户端

四、堆积：建索与 compaction

处理方向：扩 Data Node、降写入突发、调段大小策略、给 compaction 留 I/O 预算——加 Query Node 副本不会消化建索队列。

五、OOM 与容量

1. Query Node：\(\text{段数据} + \text{索引} + \text{副本因子}\)（第 14 篇）。
2. Proxy：超大并发 × 大候选归并缓冲（第 4、9 篇）。
3. Data Node：建索峰值（向量矩阵 + 图结构）（第 8、10 篇）。
4. Growing：Streaming Node 内存策略与 flush 是否触发（第 5 篇）。

对象存储「便宜」不降低 内存工作集；副本用 QPS 换的是 RAM。

六、写入路径检查单

1. Coordinator 是否单活跃且健康（第 4 篇）。
2. 是否处于 WAL 迁移 / Wait for Ready（第 5、14 篇）。
3. shard/channel 是否倾斜到单 Streaming Node（第 3 篇）。
4. Woodpecker 模式是否为 MemoryBuffer 导致写延迟达数百毫秒量级（第 5 篇官方模式说明）。

七、开放问题

1. 统一「召回 / 延迟 / 队列深度」的红黄绿看板模板。
2. 自动区分 GuaranteeTs 等待与 Knowhere 计算的 tracing span。
3. 多集群联邦排障时的时钟与 TSO 对齐。

八、小结

先定性症状，再映射到段、水位、过滤、队列、对象与副本；最后才拧 ef。选型与阅读地图见 第 18 篇。

参考资料

1. 本系列第 2–16 篇机制结论（见各篇参考资料）。
2. 系列 index、PLAN.md。

返回 系列目录 ｜ 上一篇：Lance 对照 ｜ 下一篇：选型与阅读地图