@Rocky Does the StarRocks query engine provide any suite for stress testing — for example, how many queries per second it can handle, or the query limit beyond which it hits OOM, etc.?

StarRocks does not provide a single "all-in-one" stress testing GUI, but it offers a comprehensive set of benchmarking toolkits and resource management features to perform and control stress testing. 1. Performance Benchmarking Suites StarRocks provides specialized tool packages for industry-standard benchmarks. These are the primary "suites" used to test QPS and latency under load: * SSB (Star Schema Benchmark): Commonly used for testing high-concurrency, single-table, and multi-table join performance. StarRocks provides a SSB Benchmarking guide and scripts (often found in the

bin

directory of the source repo or specialized POC toolkits) to automate data generation, table creation, and query execution. * TPC-H & TPC-DS: For complex decision-support queries. StarRocks provides a

tpch-poc

toolkit that includes data generators (

dbgen

) and execution scripts (

benchmark.sh

) to measure query response times. * External Tools: For QPS/concurrency stress testing specifically, the community often uses standard tools like Apache JMeter, K6, or sysbench configured with the StarRocks MySQL-compatible port (9030). 2. Query Limits and OOM Prevention StarRocks has built-in mechanisms to define the "query limit" and prevent system-wide OOM (Out-of-Memory) crashes: * `query_mem_limit`: A session variable that sets the maximum memory a single query can use on each BE (Backend) node. If a query exceeds this, it is terminated to protect the node. * Resource Groups: You can create resource groups to isolate workloads. For example, you can limit a specific group to a certain percentage of CPU and memory. If a query in that group exceeds the group's limits, it can be automatically rejected or killed. * Query Queues: To prevent hitting OOM during high QPS bursts, you can enable Query Queuing. It will queue incoming queries if: * The concurrency threshold (

query_queue_concurrency_limit

) is reached. * The memory usage ratio (

query_queue_mem_used_pct_limit

) is exceeded. * Spill to Disk: By setting

SET enable_spill = true;

, StarRocks can spill intermediate results (from joins, aggregates, or sorts) to disk when memory is tight. This allows large queries to finish slowly instead of hitting an OOM error. 3. Monitoring Stress Levels To analyze how StarRocks behaves during a stress test: * Query Profile: Use

EXPLAIN ANALYZE

or check the

QueryPeakMemoryUsagePerNode

in the Query Profile to see how close a query got to the memory limit. * Audit Logs: Monitor the

fe/log/fe.audit.log

to track QPS, latency, and resource consumption for every query. * Proc Profile: Generate flame graphs for BE/FE processes to identify CPU hotspots during high-load tests. For official performance numbers or to set up a POC stress test, you can refer to the Benchmarking section of the documentation. References • faq/Others.md • quick_start/shared-nothing.md • knowledge/trouble_shooting/trouble_shooting_scripts.md • developers/mac-compile-run-test.md