My ANN_SEARCH queries are absolutely nuking my OLTP performance

A developer reports that running ANN_SEARCH vector similarity queries for a RAG pipeline in OceanBase is causing severe CPU thread starvation, with OLTP point queries that normally complete in under 1ms experiencing queueing times exceeding 400ms at around 800 concurrent vector search requests. The developer has tried adjusting tenant_max_cpu but seeks a more granular solution to cap parallel threads for ANN_SEARCH traversals, hoping to avoid moving vector workloads to a separate tenant due to cross-tenant latency and data synchronization overhead.

My ANN SEARCH queries are absolutely nuking my OLTP performance The setup is pretty straightforward: we use the same tenant for our standard real-time OLTP point-queries basic primary key lookups and our dense vector similarity searches for our RAG /en/tags/rag/ pipeline using the ANN SEARCH command with a VSAG index. On paper, this should work fine. In reality, as soon as we hit a concurrency spike—around 800 simultaneous vector search requests—the entire tenant falls apart. The symptoms are brutal. Our simple SELECT ... WHERE id = ? queries, which usually fly through in under 1ms, suddenly start lagging with queueing times exceeding 400ms. It’s not even a latency issue with the data itself; it’s a pure starvation issue. I did a deep dive into the monitoring using GV$OB PROCESSLIST to figure out what was actually happening under the hood. It looks like the parallel execution threads being spawned for the graph-based VSAG index traversals are aggressively saturating the entire CPU worker thread pool for that tenant. Basically, the heavy vector math is grabbing every available thread, leaving absolutely nothing for the lightweight transactional queries to breathe. I tried a few things to fix this, but nothing has stuck: Resource Isolation attempt: I tried adjusting the tenant max cpu boundaries, but since both the OLTP and the vector workloads are living inside the same tenant, the isolation isn't helping. The CPU is capped at the tenant level, but the "bad actor" the vector search is just eating everything within that cap. What I'm looking for is a way to perform a more granular deployment of resources. Does anyone know if there is a tenant-level session variable or a specific system configuration in OceanBase that can explicitly cap the maximum number of parallel threads allocated specifically for ANN SEARCH vector graph traversals? I really need to prevent the vector execution from starving the standard OLTP queries of CPU resources. I’m trying to avoid the "obvious" solution of spinning up a dedicated second tenant for the vector searches. If I move the vector work to a different tenant, I'll run into cross-tenant network latency and massive data synchronization overhead, especially since we need to perform joined queries across both datasets. We need this to work in a single tenant for the sake of our AI workflow performance. Has anyone dealt with this kind of thread starvation when running heavy LLM-related vector workloads alongside standard SQL? Any advice on tuning the parallel execution limits would be a lifesaver. Next I tried to write my own textbooks and almost lost my mind → /en/threads/7335/