Memory Management Strategies: Configuring Redis Eviction Policies

Previously in this course, we explored monitoring Redis performance, where we identified how to track memory usage metrics. In this lesson, we will shift from observation to action by configuring how Redis handles memory when it hits its limits.

Understanding Memory Limits

Redis is an in-memory store, which means its performance relies on keeping your data in RAM. However, RAM is finite. If your dataset grows larger than the available physical memory, your operating system will begin swapping to disk, causing your performance to plummet.

To prevent this, you must define a hard limit using the maxmemory directive. When Redis reaches this threshold, it must decide which data to "evict" (delete) to make room for new incoming writes. Configuring this correctly is vital for maintaining the stability of your cache-aside logic.

Configuring maxmemory

You can set the memory limit in your redis.conf file or dynamically via the CLI. To set a limit of 2 gigabytes, for example:

Bash
# Via redis-cli
CONFIG SET maxmemory 2gb

Once maxmemory is reached, Redis follows an eviction policy to free up space. You must choose a policy that matches your application’s access patterns.

Choosing Eviction Policies: LRU vs. LFU

Redis provides several strategies to choose from. While you can find a deep dive in Mastering Cache Eviction Policies: LRU vs. LFU in Redis, here are the core principles you need to know:

LRU (Least Recently Used)

LRU assumes that if you haven't touched a piece of data in a while, you probably won't need it soon. It is the default in many Redis configurations because it is highly efficient and works well for most web request caches.

LFU (Least Frequently Used)

LFU is more sophisticated. It tracks the frequency of access for each key. If you have a set of "heavy hitter" keys that are requested constantly but were last accessed a few minutes ago, LRU might accidentally evict them, but LFU will recognize their high frequency and keep them in memory.

Hands-on: Configuring Eviction

For our running project (the API cache), we want to ensure that if the cache fills up, we replace old, unused responses first.

1. Check current policy:

   Bash
   CONFIG GET maxmemory-policy
   

2. Set a recommended policy for a cache:

   Bash
   CONFIG SET maxmemory-policy allkeys-lru
   

   Note: allkeys-lru means we can evict any key in the database, including those without an expiration time. If you use expiration and TTL, you might prefer volatile-lru.

Common Pitfalls

• Setting maxmemory too low: If you set this lower than your "hot" working set, Redis will constantly evict and re-fetch data, leading to a "cache thrashing" state where your hit ratio drops to near zero.
• Ignoring the eviction policy: Using noeviction in a production environment is dangerous. It turns your database into a read-only store the moment it hits the memory limit, which usually results in application-wide downtime.
• Confusing LRU and LFU: Remember that LRU is about time, while LFU is about popularity. Choose LFU only if you have a non-uniform distribution of requests (i.e., a few keys are extremely popular).

FAQ

Does Redis delete keys immediately when they expire? No, Redis uses a combination of lazy expiration (deleting when accessed) and periodic sampling. Eviction policies, however, are strictly invoked when maxmemory is hit.

Can I see how many evictions are happening? Yes, run INFO stats and look for the evicted_keys metric. A rapidly increasing number suggests you need to increase your maxmemory or optimize your key usage.

Recap

Memory management is the final wall between a stable Redis instance and a performance bottleneck. By configuring maxmemory and selecting the right eviction policy—typically allkeys-lru for caches—you ensure that your service remains performant even under heavy load.

Up next: We will discuss designing for cache invalidation to handle data consistency between your database and your Redis cache.