Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC 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 & 11iTechGuides 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
Set a Redis memory limit with maxmemory, choose a maxmemory-policy that matches your cache’s access pattern, and assign a TTL to entries that should expire. TTL controls how long an individual entry remains eligible for use; eviction determines what Redis removes when memory reaches its limit. For AI semantic caches, also enforce hard context boundaries—such as tenant and model version—because neither TTLs nor eviction prevent an unsafe similarity match.
How eviction and TTLs work together
Redis applies the selected eviction behavior when memory reaches the configured maxmemory threshold. A TTL is an expiration time attached to a key. When it elapses, the key expires; the TTL also lets Redis reclaim entries before they are needed again. Expiration and eviction are related but distinct: a cache needs an eviction policy for memory pressure even if its entries have TTLs.
Redis Open Source supports setting maxmemory in redis.conf at startup or changing it at runtime. The threshold is not a reason to allocate every byte of physical RAM to Redis: replication and AOF buffers can require additional memory.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Set a memory limit and eviction policy
Configure the memory threshold
For a Redis Open Source instance, add a limit such as maxmemory 100mb to redis.conf. To change it at runtime, use:
#1 Best Overall
CONFIG SET maxmemory 100mb
The value is an example, not a recommended allocation. Size the limit for the host and workload, leaving headroom for memory Redis uses outside the eviction threshold. Check mem_not_counted_for_evict in INFO memory when estimating buffer use.
Choose a policy for the key mix
Set maxmemory-policy to the policy whose eligible keys and retention signal fit your workload. Redis describes allkeys-lru as a common rule of thumb when a small subset of keys is expected to receive much more traffic than the rest. LRU is approximate: Redis samples keys rather than maintaining a perfect least-recently-used ordering.
Rank #2
| Policy | Eligible keys and selection behavior | When it may fit |
|---|---|---|
allkeys-lru |
Any key; favors retaining recently used keys. | Traffic is skewed toward a frequently accessed hot set. |
allkeys-lfu |
Any key; favors retaining frequently used keys. | Repeated-use frequency is a better retention signal than recency. |
allkeys-random |
Any key; chooses candidates randomly. | Accesses are expected to be roughly uniform. |
volatile-lru, volatile-lfu, volatile-random |
Only keys with an expiration; respectively favors recency, frequency, or random selection. | Non-expiring keys share the instance and should not be eviction candidates. If no keys have TTLs, a volatile policy behaves like noeviction. |
volatile-ttl |
Only expiring keys; considers keys with the shortest remaining TTL first. | Use only when TTL assignment intentionally identifies entries that are better eviction candidates sooner. |
noeviction |
Does not evict keys; commands that would add data can fail at the memory limit. | Choose only when rejecting writes is preferable to discarding cached entries. |
allkeys-lrm, volatile-lrm |
Redis 8.6 and later: least-recently-modified candidates, with modification time updated on writes rather than reads. The volatile variant considers only expiring keys. | Consider only after confirming the deployed Redis version supports these policies. |
If disposable cache entries and data that must remain share an instance, a volatile policy can preserve non-expiring keys—but only if cache entries consistently receive TTLs. Separate cache and persistent workloads where practical to avoid coupling their memory and eviction behavior. Redis Cloud and Redis Software have their own configuration surfaces and defaults; do not assume the Redis Open Source commands or defaults apply unchanged to a managed deployment. See Redis’s key eviction documentation for policy details.
Set TTLs for AI cache entries
Base expiration on freshness
Choose a TTL from the underlying information’s freshness and invalidation requirements, not from a universal Redis recommendation. Use a shorter validity window for answers likely to become stale quickly, and define how to correct an answer that becomes invalid before expiration. Expiration alone is not an invalidation strategy for already-wrong content.
Redis expiration is per key. Set an expiration when writing an entry that should age out. In RedisVL, SemanticCache accepts a default TTL in seconds and per-store TTL options, and its documented expire method can set or refresh an entry. Check the behavior for the RedisVL version you deploy: in the RedisVL user guide, ttl=None means entries persist indefinitely, configured TTL is applied on store, and a cache hit refreshes TTL as a sliding window. If neither a default nor a per-entry TTL is supplied, that API operation does not add expiration. See the RedisVL TTL guide and RedisVL cache API.
Keep semantic matches within the right context
A semantic cache may reuse a response for a prompt that is similar rather than identical. Require hard filters for context such as tenant, locale, model version, and safety flags before considering similarity. Then tune the similarity threshold against answer quality: a loose threshold can return an answer for the wrong prompt, while a strict threshold reduces hits. Test correctness of reused answers alongside cache efficiency; a high hit rate alone does not establish that the cache is safe or useful.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Monitor behavior and tune from workload evidence
Use Redis statistics together rather than treating any one count as a verdict.
Recommended Free Tools
| Signal | Where to inspect | What it can indicate |
|---|---|---|
keyspace_hits and keyspace_misses |
INFO stats |
Whether lookups find entries, interpreted against the application’s request mix. |
evicted_keys |
INFO stats |
How often Redis has removed keys under memory pressure; rising evictions with a weak hit rate can suggest the displaced key set or policy is a poor fit. |
expired_keys |
INFO stats |
Expiration activity; unexpectedly high expiration may mean TTLs are too short or applied to the wrong keys. |
used_memory_dataset and mem_not_counted_for_evict |
INFO memory |
Dataset memory and memory outside the eviction threshold, including buffers to account for when sizing the instance. |
| Rejected writes or command errors | Command statistics and application/Redis error monitoring | With noeviction, or a volatile policy with no expiring candidates, write rejection can show the memory bound is blocking ingestion. |
After rollout, check whether important entries repeatedly expire before reuse and whether eviction is displacing useful cache content. Adjust TTLs and policy based on those observations, then benchmark against the actual workload and freshness constraints. Do not assume a particular hit-rate gain, latency reduction, or cost saving from a policy choice.
Quick Recap
Best Value
Redis eviction and TTL setup checklist
- Set a deliberate
maxmemoryvalue and leave headroom for replication or persistence buffers. - Choose the policy based on eligible keys, access pattern, and the consequence of eviction versus rejected writes.
- Ensure keys intended for expiration actually receive TTLs, especially with volatile policies.
- Set TTLs according to data freshness and invalidation needs; confirm RedisVL behavior for the version in use.
- For semantic caching, isolate tenant, locale, model, and safety context before similarity matching.
- Monitor hits, misses, evictions, expirations, memory, and rejected commands; tune with workload and answer-quality evidence.
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.
