Skip to main content
This page answers common operational questions about running RisingWave in production, including memory management, materialized view creation performance, and resource usage.

​
Why is the memory usage so high?

This is by design. RisingWave uses memory for in-memory caching of streaming query state — data structures like hash tables, aggregation buffers, and join state — to optimize streaming computation performance. By default, RisingWave utilizes all available memory unless specifically configured through RW_TOTAL_MEMORY_BYTES or --total-memory-bytes. This is why setting memory limits is required in Kubernetes and Docker deployments. During operation, RisingWave keeps memory usage below the configured limit. If you encounter unexpected out-of-memory (OOM) issues, see Troubleshoot out-of-memory.

​
Why is the memory for a Serving or Streaming Node not fully utilized?

RisingWave allocates a portion of total memory as reserved memory for system usage, including the process stack, code segments, allocation overhead, and network buffers.

​
Reserved memory calculation (v1.10+)

Starting from version 1.10, RisingWave calculates reserved memory using a gradient formula:
  • 30% of the first 16 GB
  • 20% of the remaining memory
Example: For a Streaming Node with 32 GB of total memory:
  • 30% of the first 16 GB = 4.8 GB
  • 20% of the remaining 16 GB = 3.2 GB
  • Total reserved memory = 8 GB
This gradient approach ensures more memory is reserved on smaller instances (where system overhead is proportionally larger) while leaving more memory available for computation on larger instances.

​
Custom reserved memory configuration

You can override the default calculation using:
  • Environment variable: RW_RESERVED_MEMORY_BYTES=8589934592 (8 GB)
  • Startup option: --reserved-memory-bytes=8589934592
The reserved memory must be at least 512 MB.
Example: On a 64 GB Streaming Node, the default reserved memory would be 14.4 GB (30% of 16 GB + 20% of 48 GB). If this is excessive for your workload, set RW_RESERVED_MEMORY_BYTES=8589934592 to allocate only 8 GB.

​
Version history of reserved memory

VersionBehavior
Before v1.9Fixed 30% of total memory as reserved
v1.9Introduced customizable reserved memory (--reserved-memory-bytes)
v1.10+Changed to gradient calculation (30% of first 16 GB + 20% of rest)

​
Why does CREATE MATERIALIZED VIEW take a long time?

The execution time for CREATE MATERIALIZED VIEW depends on two main factors:

​
1. Backfilling historical data

When a new materialized view is created, RisingWave backfills all historical data from the referenced tables and materialized views to ensure a consistent snapshot. The CREATE statement blocks until backfilling completes. How to check progress: 
SHOW JOBS;
How to run in background (non-blocking): 
SET BACKGROUND_DDL = true;
CREATE MATERIALIZED VIEW my_mv AS SELECT ...;
When BACKGROUND_DDL=true, the new materialized view remains invisible in the catalog until backfilling completes. See SET BACKGROUND_DDL for details.

​
2. High cluster latency

If the Progress column in SHOW JOBS stays at 0.0%, the cluster may be experiencing high latency that slows down streaming graph changes. See Troubleshoot high latency for diagnostic steps.

​
What does the memory and disk usage consist of?

RisingWave memory usage on a Serving or Streaming Node is divided into three components:
ComponentDescription
Storage memoryCaching data blocks, metadata, and shared buffers to improve read/write performance
Compute memoryMemory allocated for streaming computation and ad-hoc query execution
Reserved memorySystem overhead: process stack, code segments, allocation, and network buffers
Example breakdown for a Streaming Node with 8 GB total memory: 
total_memory: 8.00 GiB
    storage_memory: 2.13 GiB
        block_cache_capacity: 688.00 MiB
        meta_cache_capacity: 802.00 MiB
        shared_buffer_capacity: 688.00 MiB
    compute_memory: 3.47 GiB
    reserved_memory: 2.40 GiB
For guidance on tuning memory allocation, see Tune reserved memory.