OceanBase 4.
在同一个租户里混跑 OLTP 点查和向量搜索(ANN_SEARCH)简直是个坑,尤其是用了 VSAG 索引之后。我最近在处理一个 RAG 管道,并发量上来之后(大概 800 多个并发向量请求),原本不到 1ms 就能返回的简单主键查询,排队时间竟然直接飙到了 400ms 以上。
下一篇
要是没有 llama.cpp 这种底层优化 →
这种现象非常诡异,因为从监控看 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 线程上限,这种“资源抢占”会导致整个业务在高峰期直接瘫痪。如果有遇到过类似线程饥饿问题的开发者,建议看看有没有更优雅的配置参数能把向量计算的并行度给压下去。
免费 AI 工具箱 · 全部完全免费