Frequently asked questions (FAQ)

Answers to common questions about RisingWave performance tuning and troubleshooting.

This topic addresses frequently asked questions related to RisingWave performance, resource allocation, and troubleshooting. It serves as a quick reference and reinforces key concepts covered in the Performance Guide. For more in-depth information, refer to the linked sections.

How do I adjust the resources allocated to each streaming query?

RisingWave uses a session variable called 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?

RisingWave uses another session variable called 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`?

Both 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).

See Best practices - Resource allocation for more details.

When should I deploy a dedicated batch-serving cluster?

By default, all compute nodes run both streaming and batch queries. This can lead to resource competition, making it difficult to guarantee the performance of both query types.

If you have batch queries that require sub-second latency, a dedicated batch-serving cluster is recommended. This isolates batch query workloads, preventing resource contention with streaming jobs. It also improves the availability of batch query processing, as failures of compute nodes used for stream processing won’t affect batch queries. See Best practices - Resource allocation.

Is there any difference between configuring a compute node for stream processing only and for batch serving only?

Yes. The default configuration is optimized for streaming queries, allocating more memory to the operator cache to reduce fetching data from the object store.

When a compute node is used for batch serving only, the operator cache is not needed. You can increase the memory allocated to the block cache and meta cache to improve performance for batch queries by caching more data locally.

We recommend using this configuration for batch-serving compute nodes. For other configuration examples, check out the RisingWave repository.

What are the key performance metrics to monitor?

See Monitoring and metrics for a detailed list and explanation of the key performance indicators (KPIs) you should monitor, including CPU usage, memory usage, cache miss ratios, barrier latency, and more.

How can I tell if my streaming query is under-resourced?

Several indicators can suggest that your streaming query is under-resourced:

• High CPU utilization (see Monitoring and metrics - Resource utilization).
• High memory usage (see Monitoring and metrics - Resource utilization).
• High cache miss ratios (see Monitoring and metrics - Cache performance).
• High barrier latency (see Monitoring and metrics - Barrier monitoring and High latency).
• Backpressure (see Workload analysis and High latency).

See Best practices - Resource allocation for guidance on adjusting resources.

How can I optimize my queries for performance?

Optimizing queries involves several techniques, including:

• Using appropriate indexes: See Best practices - Query optimization.
• Tuning parallelism: Adjust streaming_parallelism and batch_parallelism as needed.
• Writing efficient SQL: Avoid common performance pitfalls like unnecessary joins, full table scans, and inefficient WHERE clauses. See Best practices - Query optimization.
• Data modeling: See Best practices - Data modeling.

What are common causes of high latency?

High latency can be caused by various factors, including:

• Resource constraints (CPU, memory, disk I/O).
• Inefficient queries.
• Backpressure.
• Network issues.
• Slow upstream sources.

See High latency for a detailed guide to diagnosing and resolving high latency problems.

What is the operator cache, and how does it affect performance?

The operator cache is a memory area used by stateful operators (like joins and aggregations) to store intermediate data and state. A larger operator cache can reduce the need to fetch data from storage (e.g., S3), improving performance. See Monitoring and metrics - Cache performance and Best practices - Resource allocation for more information.

How does data modeling affect performance?

Proper data modeling is crucial for efficient query processing. Consider factors like data types, primary keys, and how data is distributed. See Best practices - Data modeling.

What is the impact of using materialized views on performance?

Materialized views can significantly improve query performance by pre-computing results. However, they also consume resources (CPU, memory, storage). See Best practices - Using materialized views.

Where can I view the performance metrics?

You can access performance metrics through RisingWave’s Grafana dashboards. See Monitoring and metrics for details on accessing and interpreting these metrics.

For any other questions or tips regarding performance tuning, feel free to join our Slack community and become part of our growing network of users. Engage in discussions, seek assistance, and share your experiences with fellow users and our engineers who are eager to provide insights and solutions.