Redis maxmemory and Eviction Policies by Workload

Redis will use every byte you let it. On a VPS that also runs the application, Postgres, and systemd, that sentence is an outage. maxmemory is the cap. The eviction policy is what happens when the cap is hit. Together they decide whether Redis drops cold cache keys, refuses writes, or lets the Linux OOM killer pick a victim. Set both before the dataset is interesting.

A 2 GB plan is not a 2 GB Redis. The kernel, the app, and any AOF rewrite child need RAM. A working starting point is maxmemory at 40 to 50 percent of the instance if Redis shares the host, or 70 percent if Redis is the only busy process. Leave headroom for fragmentation. used_memory_rss is often larger than used_memory.

Set the cap and watch it

# /etc/redis/redis.conf
maxmemory 512mb
maxmemory-policy allkeys-lru
maxmemory-samples 5

Restart, then confirm the runtime value. CONFIG GET is the source of truth if someone changed the file but forgot to restart, or used CONFIG SET in a hurry.

redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy
redis-cli INFO memory

INFO memory reports used_memory_human, used_memory_peak_human, maxmemory_human, and mem_fragmentation_ratio. When used_memory approaches maxmemory, evictions start or writes fail, depending on the policy. When used_memory_rss climbs far above used_memory, fragmentation is eating the VPS even though Redis thinks it is under the cap. A reboot of Redis compactifies that; a policy change does not.

CONFIG SET maxmemory 256mb is allowed at runtime and is the right way to lower the cap during an incident. Persist the same value in redis.conf or the next restart undoes it.

Pick the policy from the data, not from a default

allkeys-lru evicts the least recently used key among everything. That is the right policy for a cache. Cold rows leave, hot rows stay, and the application refetches from Postgres. It is the wrong policy for a queue or for sessions you cannot rebuild: LRU will drop a session the user has not touched in a while even if its TTL has not expired.

volatile-lru and volatile-lfu evict only among keys that have a TTL. Keys without EXPIRE are never evicted. Use this when the same instance holds a cache (with TTL) and a small set of durable keys (no TTL). If you forget to set TTL on cache keys, the policy evicts nothing and you are back to OOM.

volatile-ttl evicts keys with a TTL, preferring those closest to expiry. It is a reasonable session policy if every session key has SETEX and you would rather drop almost-expired sessions than random ones.

allkeys-lfu uses frequency instead of recency. It fits caches where a key can be hot, go quiet for a minute, and become hot again. LRU would drop it during the quiet minute. LFU keeps it.

noeviction refuses writes when the cap is hit. Reads still work. Use it for queues, locks, and any dataset where dropping a key is data loss. The application must handle the error and you must alert on used_memory, because a full Redis with noeviction is a partial outage.

# cache sharing the host with the app
maxmemory 512mb
maxmemory-policy allkeys-lru

# sessions with SETEX on every key
maxmemory 256mb
maxmemory-policy volatile-ttl

# queue / locks, never drop
maxmemory 128mb
maxmemory-policy noeviction

Do not mix a noeviction queue and a huge cache in one instance unless the cache keys all have TTLs and you use volatile-lru. Even then, two instances (two ports, two systemd units, two maxmemory values) are clearer on a VPS that has the RAM.

What the VPS sees when you get this wrong

Without maxmemory, Redis grows until Linux starts reclaiming. The first victim is often the application or Postgres, not Redis. You debug a crashed Node process and miss the real cause. With maxmemory and noeviction and no alert, the app starts throwing write errors at peak traffic. With allkeys-lru on session keys, users get logged out in LRU order.

Watch evicted_keys, rejected_connections, and used_memory from INFO stats and INFO memory. A rising evicted_keys on a cache is healthy. A rising evicted_keys on a session store is a bug. On Intel Xeon Platinum hosts with High-Speed SSD, the CPU will not save you from a memory policy mismatch. The policy is the product decision.

Takeaway

Cap Redis with maxmemory, then pick allkeys-lru for caches, volatile-ttl for SETEX sessions, and noeviction for anything you cannot rebuild. You can try the three policies on a Netbay VPS in Lucknow in under 60 seconds — netbayhosts.in.