Sizing Redis `maxmemory` Correctly: Memory Reserves for Data and Operations

What Actually Limits `maxmemory`

maxmemory creates an Eviction Threshold There is no hard upper limit for the Redis process or its container. If the memory usage relevant to memory management reaches the threshold, Redis attempts to remove keys based on the selected policy. For a policy without eviction, write commands that increase memory usage may fail instead.

The key figure used_memory includes the memory allocated by Redis through its allocator. This includes not only the actual values of your application, but also management structures and other Redis memory areas. If you calculate the limit based solely on the estimated size of the user data, you are not taking this overhead into account.

Part of used_memory is excluded from the eviction test: mem_not_counted_for_evict specifies, in particular, temporary replication and AOF buffers. These buffers still require physical memory. The value is already specified in used_memory is included and therefore must not be added to this metric a second time without verification.

This does not mean that all client or replication storage is excluded from the eviction calculation. A single large command can also temporarily exceed the threshold by a significant margin. If you set maxmemory If the container reaches its full capacity, there is no reliable margin left to accommodate such spikes and additional process usage.

When planning, therefore, two questions must be answered separately: How much space do the data set and Redis overhead require within the memory management system? And how much additional reserve does the entire runtime environment require? Only by considering both perspectives together can we determine whether a chosen value below the actual memory limit is plausible.

RSS, Allocator, and Persistence Peaks

After a load spike, used_memory decrease, while used_memory_rss remains high: Although Redis has released memory via the allocator, that memory was not necessarily returned to the operating system immediately. RSS describes the process's resident memory from the operating system's perspective and is therefore a different level of observation.

Suppose a cache grows significantly during an operation and many keys expire afterward. The smaller Redis memory value does not automatically mean that the container immediately regains that amount of free memory. For the next peak, therefore, the actual consumption history is more important than the assumption that freed memory disappears immediately.

Also mem_fragmentation_ratio is not simply a fragmentation percentage. The ratio includes other process components; for the root cause analysis, you should consider it together with the available allocator_*-metrics and load history. A single ratio cannot be used to determine a universally applicable reserve.

For RDB snapshots and AOF rewrites, Redis creates a child process. By Copy-on-Write Additional physical memory pages may be required if pages are modified during the persistence run. The heavier and broader the write load during this time, the more important it is to monitor this phase during capacity planning.

Redis Administration states that, in extreme cases, write-intensive applications may require up to twice the amount of memory normally used. This is a warning about unfavorable load conditions, not a blanket multiplier. Also, do not simply add the RSS values of the parent and child processes: Shared pages would be counted multiple times; what matters is monitoring the appropriate host or container.

Replicas require their own budgets

A replica always maintains a copy of the data set and requires its own RAM to do so. The primary and the replica are therefore separate memory consumers: A reserve on the primary does not free up space in the replica's container. Plan for each member based on its own limits and observed usage.

By default, a replica ignores its configured maxmemory for its own evictions. The primary decides which keys to remove and replicates the deletions. Nevertheless, the storage states may differ, for example due to differing buffers or data structures; therefore, the same threshold does not guarantee identical utilization.

In the case of a Promotion The former replica assumes the primary role. Therefore, check not only whether it has enough space as a read replica, but also whether its storage limit and configuration can support operation as a primary. This includes, in particular, write load, replication connections, and the eviction policy in effect at that time.

Starting with Redis 7.0, the replica buffer and the replication backlog share memory. mem_clients_slaves It may therefore show zero, even though replication is using memory. Do not interpret this field in isolation, and do not add the backlog and replica buffer together without verification as if they were completely separate areas.

In addition to memory usage, the progress of data transfer is relevant to system operation: A delay exhibits different characteristics than the size of a buffer. The article on the topic explains how replication status and backlog can be classified: Redis Replication Offset. However, the actual consumption patterns of each instance remain the determining factor for the storage reserve.

Track inventory across three levels

To size the instance, you'll need values from Redis and from the environment in which the instance is running. The Observation Level determines what a number represents: Allocator usage, process RSS, and container usage are different metrics and cannot simply be added together.

With INFO memory Among other things, you'll read the Redis storage values and the configured policy. MEMORY STATS Adds details about memory allocation. Both commands are read-only; the fields available depend on the Redis version, permissions, and hosting plan.

To verify the temporal relationship, you should also check INFO persistence on persistence activity and available copy-on-write values. INFO replication Displays the role and replication status. Enter this information separately for the primary and the replica so that a role change or synchronization remains visible during evaluation.

A single value does not indicate either typical utilization or the necessary peak reserve. Therefore, collect time series data covering normal operation, write spikes, and persistence runs, and associate them with the host or container usage observed at the same time. This will also help you determine whether a high RSS value accompanies a current load or persists after a previous spike.

Calculate a robust memory budget

The starting point is the one that is actually effective Memory Limit: For a container, this limit may be lower than the host's RAM. Determine which other processes and operating system components are using this same limit. The space reserved for them is not available to Redis for data or peak loads.

Next, subtract reserves for additional RSS and allocator effects, buffers not counted toward eviction, persistence spikes, and a safety margin. The result is a preliminary maxmemory-Budget, not an internal Redis equation. The reserves must match the same limit and reflect realistic, simultaneously occurring load conditions.

Illustrative calculation example, not a measurement: From a container limit of 8 GiB, 0.5 GiB is allocated for other consumers, 0.5 GiB for additional RSS effects, 0.5 GiB for buffers excluded from the eviction calculation, 1 GiB for a persistence spike, and 0.5 GiB for a safety margin. This leaves 5 GiB as a preliminary value for maxmemory.

These figures are not a recommendation for a specific instance. The example assumes that the allocated reserves represent additional, non-overlapping contributions to the container limit. Especially during a persistence run, shared memory pages and copy-on-write can complicate the allocation; simply adding the RSS values of the parent and child processes would be unsuitable for this purpose.

Avoid Double Counts: mem_not_counted_for_evict is already included in used_memory. If you base your calculation on the total observed RSS or container usage, you must not add this buffer portion again without verifying it. The remaining eviction budget must accommodate both the dataset and the included Redis overhead; then test this approach under a comparable load.

A Comparative Analysis of Eviction Policies in Practice

The Eviction policy Determines how Redis responds to write commands when storage is scarce. It does not replace capacity planning: Even an appropriate policy requires reserves beyond what is accounted for by the eviction algorithm. The decision depends primarily on which keys can be lost and how the application responds to errors.

With a pure cache, you can allkeys-lru This works if deleted entries can be reconstructed from another source. In Redis, LRU is an approximation and not an exact global sort. Frequent evictions can trigger more requests to the backend; therefore, not only free bytes but also cache hit rate and backend capacity are important.

For data that cannot be deleted at will, noeviction Another decision: The application must be able to handle failed write operations, rather than silently assuming that data has been successfully saved. The policy is neither persistence nor protection against an OOM at the operating system or container level.

For mixed populations, the TTL discipline Crucial: A volatile-*-Policy can only select keys with an expiration time. If there are too few suitable candidates, a TTL alone does not protect against write errors. Therefore, check whether the cache and important data should really share the same instance and error handling strategy.

Session data highlights the conflict of objectives: Deleting an entry can result in the loss of session state for users, even if the application continues to run technically. Evaluate the consequences and the possibility of recovery before selecting a policy; additional background information is provided in the article on Session Management with Redis and Other Storage Solutions.

Check the reserve under load

A calculated value for maxmemory This is a starting point. Test it in an isolated environment with a comparable Redis version, data structure, and memory limit. The load should not only reflect normal operation but also write spikes and periods when persistence and replication are active simultaneously.

As you do this, watch the Container Usage or the corresponding host metrics, as well as Redis storage values. Keep track of when a snapshot or AOF rewrite is running and whether a replica is being synchronized. What matters is how much time remains until the actual threshold during overlapping events, not just during the idle period afterward.

Using the read command INFO stats Among other things, you'll track eviction counters. Analyze how these values change over time: A high historical value alone doesn't indicate whether keys are currently being evicted. Correlate rising eviction rates with cache hits and backend load, provided your application provides these metrics.

Also, track Redis OOM responses in the application and memory-related container events on the platform. Both errors can occur under similar load conditions but are related to different limits. Therefore, any alerting should take into account both the available reserve and the observed errors and their temporal progression.

Repeat the evaluation after making changes to the dataset, the write load, or persistence and replication. A promotion also changes the role of a replica and, consequently, the load profile to be tested. The results from the isolated environment do not replace the ongoing monitoring of the production instances.

Pinpoint Memory Issues

If the process RSS increases while used_memory If memory is released, first consider its usage history and previous load. Released memory does not have to be returned to the operating system immediately. The Allocator Metrics from INFO memory help with analysis; the fragmentation ratio alone does not prove either a memory leak or its cause.

Next, check whether the increase coincides with a persistence run or a synchronization. The following are used for this purpose: INFO persistence and INFO replication. A single value for buffers not included in the eviction process describes only the current state. To determine a reserve, you need observations spanning relevant load and disturbance phases.

In the case of a Redis OOM Response Check the configured policy and whether suitable keys are available for eviction. In particular, a write command may fail if Redis cannot free up enough space under the current policy. The application must handle this error rather than assuming the write operation will succeed.

In the case of a memory-related container termination, however, examine the platform events and memory usage against the container limit. Take into account persistence spikes and other memory consumers tracked within the container. A Redis OOM and a container OOM are not the same thing: the outer memory limit can be reached even without a prior Redis OOM response.

maxmemory-clients can also limit the memory used by clients. If the relevant client memory exceeds the configured threshold, Redis may disconnect high-usage clients; applications must handle connection terminations. This setting does not limit all replication connections and does not replace the overall budget or the monitoring of buffer spikes.

Weighing the Options for Redis Hosting and Architecture

If the observed reserve is insufficient under representative load, adding more RAM may be advisable if the dataset and load are to remain on a single instance. However, the additional capacity must be part of the actual effective host or container limit. A higher Redis limit alone does not create additional physical memory.

Alternatively, a Load distribution distribute memory requirements and write operations across multiple instances. This requires an appropriate partitioning of the data and separate resource allocation for each participating instance. Replicas should not be equated with a partitioning of the data set: They essentially maintain a copy and require their own RAM to do so.

An architectural change can also help—for example, separating a loss-tolerant cache from data with stricter requirements. This allows policies and capacities to be selected independently. However, neither this separation nor additional RAM nor load balancing guarantees that persistence, replication, and write spikes will not occur in the future.

When comparing Provider Limits Determine whether the reported value refers to a container limit, an instance limit, or another type of database limit. Also, find out which metrics and diagnostic commands are available, whether replicas are included in the reserved storage, and how a promotion affects available resources.

Redis Open Source, Redis Software, and Redis Cloud should be considered separately. For Redis Software, the documented database limit applies across primary and replica shards; this does not imply a corresponding rule for a single Redis OSS instance. For Redis Cloud and other hosting services, check the specific product terms and conditions for each service rather than applying this definition without verification.