Tuning Redis Maxmemory and Eviction Policies for High-Throughput Production Web Sessions

In high-concurrency web hosting and multi-tenant application environments, Redis frequently serves as the bedrock for distributed session storage, real-time rate limiting, and transient caching layers. When traffic scales rapidly, memory exhaustion is not a matter of if, but when. Relying on default Redis memory configurations in production is an operational hazard that routinely leads to sudden latency spikes, unexpected write failures, or complete daemon crashes triggered by the Linux kernel Out-Of-Memory (OOM) killer. This post breaks down how Redis handles memory allocation, the mechanics behind eviction algorithms, and how to optimize these parameters for maximum throughput and stability.

The Anatomy of Redis Memory Management

Unlike traditional relational databases that leverage disk-backed storage engines with sophisticated page caches, Redis is primarily an in-memory data store. Every key, value, metadata overhead, and internal pointer consumes physical RAM. When Redis reaches the threshold defined by the maxmemory directive, it can no longer accept write commands that allocate new memory unless an eviction policy is explicitly enabled. By default, newer Redis installations ship with maxmemory 0 (unlimited on 64-bit systems) and maxmemory-policy noeviction. Under the noeviction policy, any command that requires additional memory—such as SET, HSET, or LPUSH—will fail with an error response:

(error) OOM command not allowed when used memory > 'maxmemory'

For a session store or rate-limiting subsystem, this means active users will suddenly be blocked from logging in or executing actions because the cache is completely full. To maintain high availability, administrators must configure an appropriate memory limit and an algorithmic eviction strategy.

Eviction Policy Matrix

Redis provides several eviction policies designed to handle memory pressure differently depending on the workload characteristics. Choosing the wrong policy can degrade application performance or drop critical persistent state.

Policy Name	Description	Ideal Use Case
`noeviction`	Returns errors when memory limit is reached for write ops.	Read-only caches or strict non-lossy counters.
`volatile-lru`	Evicts the least recently used keys, but only among keys with an expiration set.	Transient caches where keys have TTLs.
`allkeys-lru`	Evicts any least recently used key regardless of TTL.	General-purpose caching layers and session stores.
`volatile-lfu`	Evicts least frequently used keys among those with an expiration set.	Analytics or tracking with expiration metadata.
`allkeys-lfu`	Evicts any least frequently used key regardless of TTL.	High-volume read scaling where hot data must persist.
`volatile-random`	Randomly evicts keys that have an expiration set.	Uniform access patterns with short TTLs.
`allkeys-random`	Randomly evicts any key in the database.	Rare; useful for chaotic load testing.
`volatile-ttl`	Evicts keys with the shortest remaining time-to-live.	Time-sensitive queue states or temporary staging.

LRU vs. LFU: Understanding Approximation Algorithms

It is critical to note that Redis does not implement a true, exact Least Recently Used (LRU) or Least Frequently Used (LFU) algorithm. Exact tracking requires maintaining massive doubly linked lists and reference structures that introduce severe CPU overhead and lock contention under high concurrency. Instead, Redis uses an approximation algorithm:

It samples a small number of keys (controlled by maxmemory-samples, defaulting to 5).
It evicts the best key among the sampled set.
Starting with Redis 4.0, the sampling pool mechanism was refined to make the approximation extremely close to true LRU while maintaining negligible CPU overhead.

For high-throughput workloads, tuning the sample size represents a direct trade-off between CPU utilization and eviction accuracy:

# Increase sample size for better accuracy at a minor CPU cost
maxmemory-samples 10

Configuring Redis for Production Scale

To configure your production Redis instance safely, you must define a strict memory ceiling that leaves adequate head-room for the Linux kernel's fork operations during RDB snapshots and AOF rewrites. When Redis executes a BGSAVE, it forks the main process using copy-on-write (CoW). If your system has 16GB of RAM and Redis uses 14GB, a write-heavy workload during a snapshot can cause memory usage to spike past physical limits, invoking the kernel OOM killer.

Recommended redis.conf Tuning

Implement the following directives in your redis.conf to establish a resilient memory safety net:

# Set maximum memory ceiling, leaving 20 percent headroom for CoW operations
maxmemory 12gb

# Evict any key using LFU to preserve frequently accessed user sessions
maxmemory-policy allkeys-lfu

# Tune sample size for high-concurrency accuracy
maxmemory-samples 8

# Disable lazy freeing if CPU is constrained, enable if high delete throughput causes pauses
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes

Monitoring and Diagnostics

Preventative tuning must be validated through rigorous monitoring. Use the INFO memory command regularly to track key metrics:

redis-cli INFO memory

Key indicators to watch include:

used_memory: Actual physical memory consumed by Redis.
used_memory_peak: The highest memory footprint recorded since startup.
evicted_keys: The cumulative count of keys evicted due to maxmemory. A rapidly climbing number during normal traffic hours indicates your memory limit is too low or your data set is growing unboundedly.

By carefully matching your eviction policy to your application architecture—such as utilizing allkeys-lfu for session caches where user activity frequency dictates retention—you can achieve predictable performance, prevent kernel OOM disruptions, and maintain seamless uptime under extreme production loads.