To execute 20,000 parallel complex queries (or high QPS) on a table with 22 million rows, you need a configuration that prioritizes high-throughput planning and CPU efficiency. While 22 million rows is a relatively small dataset for StarRocks, the extreme concurrency requirement is the primary bottleneck. 1. Cluster Architecture: Scaling for Concurrency A standard HA cluster (3 FEs) is not enough for 20,000 concurrent requests. You must scale the FrontEnd (FE) layer horizontally to handle connection management and query planning. * FE Configuration: Deploy at least 5–8 FE nodes (1 Leader, 2 Followers, and 3–5 Observers). * Observer FEs: These nodes handle query planning and execution for read requests without participating in the Raft metadata election, making them ideal for scaling read concurrency. * Max Connections: Increase the

qe_max_connection

parameter in

fe.conf

(default is 4096) to at least 10,000 or more per FE to accommodate the 20,000 parallel connections. * Load Balancing: Use a proxy like ProxySQL, Nginx, or F5 in front of the FEs to distribute the 20,000 connections evenly across all FE nodes. 2. Performance Tuning: The "Concurrency Mode" For massive concurrency, you must prevent a few queries from hogging all CPU cores. * Pipeline DOP: Set

pipeline_dop = 1

. * By default, StarRocks tries to use many cores for a single query. In high-concurrency scenarios, this causes massive context switching. Setting

pipeline_dop

to 1 forces each query to use fewer resources, allowing the CPU to handle more queries in parallel. *

SET GLOBAL pipeline_dop = 1;

* Query Cache: Enable the Query Cache. If these 20,000 queries have repetitive patterns or share intermediate results, the Query Cache can improve efficiency by 3x to 17x. *

SET GLOBAL enable_query_cache = true;

* Page Cache: Ensure the BE Page Cache is large enough to keep the entire 22M row table in memory to avoid disk I/O. 3. Resource Management & Protection To prevent a "thundering herd" from crashing the cluster, use Resource Groups and Query Queues. * Query Queues: Enable global query queuing to buffer requests if the CPU or memory hits a saturation point. *

SET GLOBAL enable_query_queue_select = true;

*

SET GLOBAL query_queue_concurrency_limit = 1000;

(Set this based on your BE capacity). * Resource Groups: Create a specific resource group for these queries with a strict

concurrency_limit

to ensure other system tasks (like data loading) still have resources. 4. Hardware Estimation While the "complex" nature of your queries determines the exact core count, you can use this rough capacity planning formula: $$Estimated\ Cores = \frac{\text{Scan Rows} / \text{Cores Processing Power}}{\text{Response Time}} \times \text{QPS}$$ * Estimated BE Nodes: For 20,000 QPS on 22M rows, assuming each query takes roughly 200ms–500ms of CPU time, you would likely need a cluster of 20 to 40 BE nodes, each with 32 or 64 cores. * Memory: 22M rows is small, so 128GB RAM per BE is more than sufficient, provided you focus on CPU-intensive instances (e.g., AWS c6g or c7g). 5. Essential OS-Level Limits Modify

/etc/sysctl.conf

and

/etc/security/limits.conf

on all nodes to support the high number of threads and sockets: *

vm.max_map_count = 262144

*

kernel.threads-max = 120000

*

kernel.pid_max = 200000

*

net.core.somaxconn = 1024

(or higher) Recommendation: Start with 5 FE Observers and 20 BE nodes (32-core each), set

pipeline_dop = 1

, and use a Load Balancer. Monitor the

fe_connection_total

and

be_cpu_utilization

metrics to scale further. References • administration/management/BE_configuration.md • faq/Sql_faq.md • faq/Deploy_faq.md

• introduction/Architecture.md • deployment/plan_cluster.md