> ## Documentation Index
> Fetch the complete documentation index at: https://docs.risingwave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<AccordionGroup>
  <Accordion title="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](/performance/best-practices#resource-allocation) for more details.
  </Accordion>

  <Accordion title="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](/sql/commands/sql-create-index).

    In short, it's rarely necessary to change `batch_parallelism`.
  </Accordion>

  <Accordion title="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](/performance/best-practices#resource-allocation) for more details.
  </Accordion>

  <Accordion title="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](/performance/best-practices#resource-allocation).
  </Accordion>

  <Accordion title="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](https://github.com/risingwavelabs/risingwave/blob/main/src/config/serving-only.toml) for batch-serving Compute Nodes. For other configuration examples, check out the [RisingWave repository](https://github.com/risingwavelabs/risingwave/tree/main/src/config).
  </Accordion>

  <Accordion title="What are the key performance metrics to monitor?">
    See [Monitoring and metrics](/performance/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.
  </Accordion>

  <Accordion title="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](/performance/metrics#resource-utilization)).
    * High memory usage (see [Monitoring and metrics - Resource utilization](/performance/metrics#resource-utilization)).
    * High cache miss ratios (see [Monitoring and metrics - Cache performance](/performance/metrics#cache-performance)).
    * High barrier latency (see [Monitoring and metrics - Barrier monitoring](/performance/metrics#barrier-monitoring) and [High latency](/performance/troubleshoot-high-latency)).
    * Backpressure (see [Workload analysis](/performance/workload-analysis) and [High latency](/performance/troubleshoot-high-latency)).

    See [Best practices - Resource allocation](/performance/best-practices#resource-allocation) for guidance on adjusting resources.
  </Accordion>

  <Accordion title="How can I optimize my queries for performance?">
    Optimizing queries involves several techniques, including:

    * **Using appropriate indexes:** See [Best practices - Query optimization](/performance/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](/performance/best-practices#query-optimization).
    * **Data modeling**: See [Best practices - Data modeling](/performance/best-practices#data-modeling).
  </Accordion>

  <Accordion title="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](/performance/troubleshoot-high-latency) for a detailed guide to diagnosing and resolving high latency problems.
  </Accordion>

  <Accordion title="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](/performance/metrics#cache-performancee) and [Best practices - Resource allocation](/performance/best-practices#resource-allocation) for more information.
  </Accordion>

  <Accordion title="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](/performance/best-practices#data-modeling).
  </Accordion>

  <Accordion title="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](/performance/best-practices#using-materialized-views).
  </Accordion>

  <Accordion title="Where can I view the performance metrics?">
    You can access performance metrics through RisingWave's Grafana dashboards. See [Monitoring and metrics](/performance/metrics) for details on accessing and interpreting these metrics.
  </Accordion>

  <Accordion title="What if my batch query hits the distributed query limit?">
    You can check for hanging queries that might be consuming resources by running the [`SHOW PROCESSLIST`](/sql/commands/sql-show-processlist) command. Identify the slowest hanging queries and terminate them using the `KILL` command. This helps free up resources so your batch query can proceed.
  </Accordion>
</AccordionGroup>

For any other questions or tips regarding performance tuning, feel free to join our [Slack community](https://www.risingwave.com/slack) 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.