What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Redis can evict expiring session keys while still accepting writes, then reject new writes when no eligible keys remain. That sequence is what Sergey Shinder describes in a first-person account of users being logged out for roughly two weeks before a login outage. His explanation aligns with Redis’s documented volatile-lru behavior, though the incident details are not independently corroborated.
What happened in the reported outage?
Shinder says the team used one Redis cluster for both page cache and user sessions, with expirations on both. In April, they added “recently viewed” lists without expiration. By May, users had been getting logged out for roughly two weeks; on a Thursday afternoon, login stopped working and application logs showed OOM command not allowed when used memory > 'maxmemory'. The account does not specify the year, Redis version, topology, or scale, and its incident details are the author’s report rather than independently verified telemetry. Shinder’s account
The mechanism is consistent with Redis documentation: the configured eviction policy controls what Redis may remove when a write would exceed maxmemory. With volatile-lru, only keys that have an expiration are candidates. As the permanent recently viewed keys accumulated, Redis could evict expiring cache and session keys to make room. Once no eligible expiring keys remained, the policy could no longer free memory, and writes began failing at the limit. Redis eviction documentation
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Why were users logged out before Redis refused writes?
Under volatile-lru, a session key with a TTL can be evicted before its scheduled expiration when Redis needs memory. The application then finds no session key and may treat the user as logged out. This can happen while other writes still succeed, because Redis still has eligible expiring keys to remove.
#1 Best Overall
When there are no keys with expirations left to evict, a volatile policy behaves like noeviction. At the memory limit, commands that would add data return errors; reads of existing keys can still work. If login requires writing a new session, that error can make login fail even though Redis remains able to serve reads. Redis eviction documentation
What does volatile-lru evict?
It evicts the least-recently-used keys among keys that have an expiration set. It does not make every key in the database eligible. A key without a TTL is excluded from the candidate set, so permanent data can consume memory while expiring data—including sessions—gets removed.
Rank #2
Redis supports setting expirations with EXPIRE or with command options such as SET ... EX. When the TTL elapses, the key is destroyed; while the TTL is present, it also determines eligibility for volatile eviction policies. Redis key-expiration documentation
Free tools Windows power users keep installed
One-click scans. No signup required.
How do eviction policies differ when memory is full?
| Policy | Eligible keys | When memory is full | Suitable when |
|---|---|---|---|
volatile-lru |
Keys with an expiration; least-recently-used among them | If no expiring keys remain, new data-producing commands can fail, as under noeviction. |
Only if expiring keys are acceptable eviction candidates and permanent keys cannot silently crowd out protected data. |
allkeys-lru |
All keys; least-recently-used | Redis can evict any key to make room, so protected sessions or durable state may be lost if stored there. | Disposable cache data for which losing any cached key is acceptable. |
noeviction |
No keys are evicted | New data-producing commands return errors; reads of existing keys continue. | Data that must not be evicted, provided the application can handle write errors and capacity is managed. |
Redis documents these distinct tradeoffs and suggests considering separate instances for cache and persistent keys where possible. A policy is not a substitute for deciding which data may be lost, sizing capacity, or designing persistence and failover for the system’s requirements. Redis eviction documentation
How can you prevent this failure pattern?
- Separate workloads by loss tolerance. Keep disposable cache data apart from sessions or other state whose removal breaks user flows. The incident team reports moving recently viewed lists to Postgres, splitting cache and session workloads, and using
allkeys-lrufor cache with a separatenoevictionsession Redis. - Make TTL expectations explicit. Require a TTL for cache and session writes, and make permanent storage an explicit choice. Shinder says the team changed its client wrapper to reject writes without a TTL unless the caller declared permanent storage.
- Size protected stores for peak use. A no-eviction session store avoids memory-pressure eviction, but writes can still fail if it reaches its limit. The reported team sized that store for peak usage with headroom; its account does not establish a universally suitable capacity margin.
- Alert on symptoms, not just fullness. Shinder reports alerting on any session-store eviction, monitoring the proportion of expiring keys, and setting a memory alert at 70%. That 70% threshold was specific to the team, not a general Redis benchmark.
What should you monitor in Redis?
Redis’s INFO output exposes memory measurements, evicted_keys, expired-key counts, and time spent above maxmemory. These help distinguish ordinary expiry from memory-pressure eviction and show whether the store is approaching its configured limit. Redis INFO documentation
Also monitor application-side write errors, especially out-of-memory errors, and test the login path when the session store is full. The incident account mentions expiry counts by database under INFO keyspace; confirm the relevant fields against the Redis version and configuration you operate rather than assuming that exact view is universal.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
