混合负载下OceanBase 4.0向量搜索线程饥饿成因与排查指南
搭建 RAG 检索管道时，为了兼顾低延迟与数据一致性，开发团队常将向量数据与核心业务数据部署在同一租户内。这种混部方案在 OceanBase 4.0 环境下隐藏着隐患：当 ANN_SEARCH 向量搜索的并发请求增加，VSAG 索引执行图遍历时会大量吞噬并行线程，导致原本毫秒级响应的 OLTP 点查被迫排队。
并发量触及 800 阈值附近时，线程饥饿效应变得显著。主键查询耗时从不足 1ms 激增至 400ms 以上，延迟延迟源于队列等待而非计算过载。此时 CPU 通常已满负荷运转，执行以下语句可观测线程状态：
SELECT * FROM GV$OB_PROCESSLIST WHERE STATE = 'Executing' AND QUERY LIKE '%ANN_SEARCH%';
排查结果指向 VSAG 索引的图遍历过程，其抢占大量线程槽位构成了性能瓶颈。
共享线程池引发的雪崩效应
OceanBase 采用租户内共享 CPU 工作线程池的调度模型。VSAG 索引为提速检索，会发起大规模并行扫描，瞬间耗尽可用线程。轻量级 OLTP 事务虽计算极简，却因无线程可用而陷入等待。这种资源挤兑使高并发向量搜索演变为租户级瓶颈，不仅消耗自身算力，更剥夺了同类业务的其他执行机会。
租户隔离的局限性
常规的资源隔离手段难以化解内部竞争。调增 tenant_max_cpu 仅能划定租户对集群资源的边界，防止波及邻近租户，却无法管控租户内部不同任务间的线程争夺。若不愿承受拆分租户带来的跨网延迟及同步成本，便需聚焦于租户内更精细的控制，锁定向量图遍历的 CPU 线程占用。
定位线程占用的关键步骤
利用 GV$OB_PROCESSLIST 监控 Executing 状态线程分布是排查核心。单纯 CPU 满载不具备诊断价值，唯有结合进程列表确认 ANN_SEARCH 占据主导，方能锁定向量搜索导致的线程抢占。一旦确认分布，核心任务转为压低向量计算并行度，避免图遍历一次性清空共享执行线程池。
会话级并行控制的空白
当前缺乏直接限定单次向量查询并行度的会话变量。针对 VSAG 索引这类高计算、多线程操作，依赖数据库自动调度不足以平息内部资源冲突。若无机制约束向量图遍历的线程上限，高峰期 OLTP 资源仍将被挤占。
上线前须对“向量检索 + 点查”混合负载进行压测，单一 QPS 指标不具备参考意义。若响应呈非线性恶化，应立即检查线程池状态，并通过业务层限流或探寻底层并行参数来缓解抢占。
全部回复 （4）
想当场把话说完？进全球 AI 聊天室，登录就能开口。
RAG 要是没做好资源隔离，向量搜索抢光线程真能把人搞崩溃；上线前把向量检索和点查放在同一场景压测，并监控 ANN_SEARCH 的线程占用。
资源隔离没弄好简直是噩梦，好奇你最后是用哪个方案把资源切开的？我在构建 RAG（检索增强生成）管道时，发现将向量数据与业务数据放在同一个租户中会导致性能问题。具体来说，当向量搜索（ANN_SEARCH）并发量上升时，它会通过极高的线程占用，直接“挤死”原本极快的 OLTP 点查请求。我在并发向量请求达到 800 左右时，系统出现了极其诡异的性能波动。原本主键查询的响应时间不到 1ms，但此时却突然飙升至 400ms 以上。这种延迟增加并不是因为数据库在执行复杂的计算，而是请求在排队。通过监控发现 CPU 确实处于满载状态，但通过执行 SELECT * FROM GV$OB_PROCESSLIST WHERE STATE = 'Executing' AND QUERY LIKE '%ANN_SEARCH%'; 深入分析后才发现，真正的元凶是 VSAG 索引在进行图遍历时产生了海量的并行执行线程。
赶紧试下分租户隔离，不然OLTP被拖慢到几秒一次响应简直是噩梦。在构建 RAG（检索增强生成）管道时，很多开发者为了追求低延迟和数据一致性，倾向于将向量数据与业务数据放在同一个租户中。但实际压测中发现，这种“混跑”模式在 OceanBase 4.0 中潜伏着一个巨大的性能陷阱：当向量搜索（ANN_SEARCH）并发量上升时，它会通过极高的线程占用，直接“挤死”原本极快的 OLTP 点查请求。我遇到的具体场景是，在并发向量请求达到 800 左右时，系统出现了极其诡异的性能波动。原本主键查询的响应时间不到 1ms，但此时却突然飙升至 400ms 以上。这种延迟增加并不是因为数据库在执行复杂的计算，而是请求在排队。通过监控发现 CPU 确实处于满载状态，但通过执行 SELECT * FROM GV$OB_PROCESSLIST WHERE STATE = 'Executing' AND QUERY LIKE '%ANN_SEARCH%'; 深入分析后才发现，真正的元凶是 VSAG 索引在进行图遍历时产生了海量的并行执行线程。
把向量搜索并行度调低才救回来，之前点查慢得我想砸电脑。当并发向量请求达到 800 的时候，原本 1ms 的主键查询飙升到 400ms+，不是执行变慢，是请求在排队，CPU 满载但其实是 VSAG 图遍历启动了海量并行线程把整个租户的线程池塞满了，导致轻量级的 OLTP 点查抢不到线程只能苦苦等待。
定位方法就是通过
SELECT * FROM GV$OB_PROCESSLIST WHERE STATE = 'Executing' AND QUERY LIKE '%ANN_SEARCH%';实时监控 Executing 状态下 ANN_SEARCH 占据的线程槽位，如果绝大多数都是向量搜索线程，那就确认了元凶。常规的
tenant_max_cpu调整没用，它只能管租户对集群的资源限制，无法解决租户内部向量检索和点查之间的抢占，所以我没打算拆分第二个租户，就尝试降低单次向量查询的并行度，但目前会话级缺少一个直接限制 VSAG 图遍历线程上限的变量，只能靠业务层限流来应急，希望 OceanBase 后续能加一个类似ob_enable_ann_parallel_limit这样的会话级参数，直接让开发者能在租户内部设置向量检索的 CPU 线程上限，省得业务高峰期整个链路直接瘫痪。压测的时候千万别只看单一向量检索 QPS，一定要模拟“向量检索 + 点查”的复合场景，一旦发现响应时间非线性增长，就立即检查线程池状态，评估是否需要降并行度或加业务限流。