OceanBase 4.

早八人码农 专家 18小时前 305 浏览 11 点赞 约 1 分钟

在同一个租户里混跑 OLTP 点查和向量搜索(ANN_SEARCH)简直是个坑,尤其是用了 VSAG 索引之后。我最近在处理一个 RAG 管道,并发量上来之后(大概 800 多个并发向量请求),原本不到 1ms 就能返回的简单主键查询,排队时间竟然直接飙到了 400ms 以上。

这种现象非常诡异,因为从监控看 CPU 确实满了,但并不是因为计算量太大,而是线程被占满了。我通过 GV$OB_PROCESSLIST 查了一下,发现 VSAG 索引在做图遍历时会产生大量的并行执行线程,这些线程直接把租户内部的 CPU 工作线程池给塞爆了,导致轻量级的事务查询根本抢不到线程执行。

最让人头疼的是,我尝试过调整 tenant_max_cpu 来限制资源,但因为向量查询和 OLTP 查询都在同一个租户里,这个配置只能限制租户对集群的总资源占用,没法在租户内部做细粒度的隔离。

目前我的排查思路和尝试方案如下:

一、确认资源瓶颈
通过以下 SQL 观察线程状态,确认是否大量线程处于等待或被向量搜索占据:

SELECT * FROM GV$OB_PROCESSLIST WHERE STATE = 'Executing' AND QUERY LIKE '%ANN_SEARCH%';

二、排查隔离手段
由于不想为了避免跨租户网络延迟和数据同步开销而专门分出第二个租户,我现在在找有没有能限制 ANN_SEARCH 并行度的会话级变量。

目前的困境是,如果不能在租户内部给向量图遍历设置一个 CPU 线程上限,这种“资源抢占”会导致整个业务在高峰期直接瘫痪。如果有遇到过类似线程饥饿问题的开发者,建议看看有没有更优雅的配置参数能把向量计算的并行度给压下去。

求助OceanBaseVSAG

全部回复 (4)

小Kevin在路上 中级 18小时前
我也遇到过,后来调小了向量搜索的并行度,点查才快回来。
0 回复
数据分析师大山 中级 18小时前
之前搞RAG也被坑过,资源抢占太凶,得给点查留点口粮。
0 回复
创业者阿杰 中级 18小时前
@数据分析师大山 资源隔离要是没做好真的心累,你当时是用什么方案切分资源的?
0 回复
架构师老刘 中级 18小时前
试过分租户跑没,把向量搜单独拎出来,不然这资源抢得没完。
0 回复

发表回复

支持 Markdown 格式