Memory Used vs Maxmemory %, Redis

​

At a glance

The percentage of Redis’s configured memory ceiling that the dataset currently occupies: used_memory divided by maxmemory. For Redis, memory is not just a resource, it is effectively the disk: the entire dataset lives in RAM, and maxmemory is the hard wall. As usage approaches that wall, Redis starts evicting keys according to its maxmemory-policy, and if the policy is noeviction it starts rejecting writes outright. This is the single most important capacity gauge on a Redis board, which is why it sits in the Executive Overview as a Hero card: it tells you, at a glance, how much runway you have before evictions or write failures begin.

​

Calculation

memory_used_pct = (used_memory / maxmemory) * 100

• used_memory is the bytes Redis’s allocator has committed for the dataset and internal structures, as reported by INFO memory. It is the figure Redis compares against maxmemory when deciding whether to evict.
• maxmemory is the configured ceiling. Crucially, Redis enforces the policy against used_memory, not against the OS-reported RSS, so this card mirrors the exact number Redis uses for its own eviction decisions.

• Approaching 100%. Once used_memory reaches maxmemory, Redis applies the maxmemory-policy. With an eviction policy (for example allkeys-lru, volatile-lru, allkeys-lfu, volatile-ttl) Redis removes keys to make room for new writes, so the dataset stays at the ceiling and you see eviction activity. With noeviction, Redis stops accepting write commands and returns an out-of-memory error to clients while still serving reads.
• The 0 special case. If maxmemory is 0, there is no Redis-imposed limit; Redis will grow until the OS runs out of RAM and the process is killed (OOM) or swaps. In that mode the meaningful ceiling is total system memory, so the card uses system RAM as the denominator where available, and you should pair it closely with Memory Fragmentation Ratio to catch swap early.

​

Worked example

1. The instance is on the edge of eviction. At 94% with volatile-lru, the next burst of writes will push usage to the ceiling and Redis will begin evicting the least-recently-used keys that have a TTL set. Right now evicted_keys is still flat, so eviction has not started, but there is almost no runway left during a traffic peak.
2. The policy choice has a sharp consequence here. volatile-lru only evicts keys that have a TTL. If a large share of memory is held by keys with no TTL (for example permanent config blobs or a leaked namespace), Redis cannot evict them and may run out of evictable candidates, effectively behaving like noeviction for the non-expiring keys and starting to reject writes. The DBA should check how much of the dataset is TTL-bearing.
3. There are three levers, in order of speed. Fastest: raise maxmemory if the node has spare RAM (CONFIG SET maxmemory 8gb), buying immediate headroom. Next: find and fix the growth (audit TTLs, hunt for a key leak with --bigkeys and keyspace sampling). Slowest but cleanest: shard or move cold data off the instance. The card buys the time to choose deliberately rather than reacting to a write-rejection incident.

Capacity decision at 20:10 UTC on 18 Feb 26:
  - Usage:                 5.64 GB / 6.00 GB = 94%
  - Runway at this rate:   ~0.36 GB before eviction begins
  - Policy:                volatile-lru (only TTL-bearing keys evictable)
  - Risk:                  if non-TTL keys dominate -> writes start failing
  - Levers:
      immediate  -> CONFIG SET maxmemory 8gb (if node has RAM)
      short term -> audit TTLs / hunt key leak (redis-cli --bigkeys)
      lasting    -> shard cold data off this instance

1. 90% is a runway warning, not a failure. At 90 to 95% you still have time to act before evictions or write rejections start. The whole point of a Hero gauge is to give you that lead time; do not wait for 100%.
2. The eviction policy decides what “full” means. Under an eviction policy, full means keys silently disappear (cache misses rise). Under noeviction, full means writes fail loudly. Know your policy before you read this card, because the symptom of “full” is completely different between them.
3. Raising maxmemory is a tactic, not a fix. Bumping the ceiling buys headroom but can mask a key leak or missing TTLs that will simply fill the new ceiling too. Pair this card with Total Keys (db0) and Evicted Keys / minute to tell organic growth apart from a leak.

​

Sibling cards DBAs should reference together

​

Reconciling against the source

INFO memory for used_memory, used_memory_human, maxmemory, maxmemory_human, maxmemory_policy, and used_memory_peak. The used_memory figure here is exactly what this card divides by maxmemory. CONFIG GET maxmemory and CONFIG GET maxmemory-policy to confirm the ceiling and the eviction behaviour. INFO stats for evicted_keys and expired_keys to see whether the ceiling is being hit (evictions climbing). MEMORY DOCTOR for Redis’s own plain-language read on memory health. ElastiCache / MemoryDB: the DatabaseMemoryUsagePercentage CloudWatch metric and the node group’s maxmemory reserved-memory settings; AWS reserves some memory for overhead, so the console % can differ slightly from a raw used_memory / maxmemory.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre