Answers to common questions about RisingWave performance tuning and troubleshooting.
How do I adjust the resources allocated to each streaming query?
streaming_parallelism
to control the parallelism of streaming queries. This variable affects all streaming queries created after the variable is set within the same session.Suppose you have a RisingWave cluster with 3 compute nodes, each with 8 CPUs. By default, streaming_parallelism
is set to 0, allowing a streaming query to access a maximum of 24 CPUs (3 nodes * 8 CPUs/node). However, reaching 100% CPU utilization may not occur in reality due to factors like insufficient data ingestion or lightweight computations. If you set streaming_parallelism
to 2, the maximum CPU resources streaming queries can use is 3 nodes * 2 CPUs/node = 6 CPUs total.If you have multiple streaming queries, their CPU resource allocation is approximately proportional to the streaming_parallelism
value when the query was created, if the total CPU demand exceeds the available resources. Otherwise, each query gets the resources it needs.Don’t worry about setting a perfect value initially. RisingWave supports runtime adjustment of streaming_parallelism
, so you can tweak it as you become more familiar with your queries’ resource requirements. See Best practices - Resource allocation for more details.How do I adjust the resources allocated to each batch query?
batch_parallelism
, which works similarly to streaming_parallelism
but applies to batch queries.It’s generally not recommended to frequently run ad-hoc OLAP queries that process huge amounts of input data using RisingWave. While RisingWave can handle such queries, it’s not optimized for this use case and will not outperform a dedicated column-based OLAP system. It’s recommended to sink output from RisingWave to a dedicated OLAP database for such queries.RisingWave is well-suited for batch queries that can be accelerated by indexes and/or process a relatively small number of rows. These queries typically complete in milliseconds to seconds and don’t require significant CPU resources. For details about creating indexes, see CREATE INDEX.In short, it’s rarely necessary to change batch_parallelism
.What are the differences between `streaming_parallelism` and `batch_parallelism`?
streaming_parallelism
and batch_parallelism
control CPU resource allocation, but they apply to different query types:streaming_parallelism
: Limits CPU resources for streaming queries (those that continuously process data). It affects all new streaming queries within the same session after the variable is set.batch_parallelism
: Limits CPU resources for batch queries (one-time queries that process a finite dataset).When should I deploy a dedicated batch-serving cluster?
Is there any difference between configuring a compute node for stream processing only and for batch serving only?
What are the key performance metrics to monitor?
How can I tell if my streaming query is under-resourced?
How can I optimize my queries for performance?
streaming_parallelism
and batch_parallelism
as needed.WHERE
clauses. See Best practices - Query optimization.What are common causes of high latency?
What is the operator cache, and how does it affect performance?
How does data modeling affect performance?
What is the impact of using materialized views on performance?
Where can I view the performance metrics?