Redis INFO Analyzer

Paste the output of INFO, or INFO all. This computes the ratios nobody remembers the formula for and flags the values that mean something is wrong, with what to do about each.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Analyze. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

Swapping

A fragmentation ratio below 1, the worst signal in INFO

# Memory
used_memory:3221225472
maxmemory:4294967296
mem_fragmentation_ratio:0.72
# Stats
keyspace_hits:12000
keyspace_misses:48000
evicted_keys:91043

Writes refused

A failed background save, which makes Redis reject every write with MISCONF

# Persistence
rdb_last_bgsave_status:err
# Memory
used_memory:1000000
maxmemory:0

A healthy instance

What normal looks like, so the concerning values above are recognisable

# Server
redis_version:7.2.4
# Memory
used_memory:1073741824
maxmemory:4294967296
mem_fragmentation_ratio:1.08
# Stats
keyspace_hits:98000
keyspace_misses:2000
evicted_keys:0

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Reading a single INFO sample as a rate

    keyspace_hits, expired_keys, evicted_keys and the rest count from startup. On an instance up for a month, a collapse an hour ago is averaged away to nothing.

    Instead:Take two samples a minute apart and subtract. The difference is the rate.

  2. Ignoring a fragmentation ratio below 1

    Below 1 means the OS has swapped part of the dataset to disk. Redis is single threaded, so a page fault stalls every client. It is the worst number in INFO and it looks like a small one.

    Instead:Fix the memory pressure or disable swap for the process. Tuning Redis will not help.

  3. Treating evicted_keys and expired_keys as the same thing

    Expired means a TTL elapsed, which was intended. Evicted means memory pressure removed a key that had not expired, which for a datastore is silent data loss.

    Instead:Alert on evicted_keys separately, and at a threshold of zero for anything that is not a cache.

Almost every counter here is a total, not a rate

This is the most common mistake made with INFO, and it makes a single sample much less useful than it looks.

Counters run from the last restart

keyspace_hits, keyspace_misses, expired_keys, evicted_keys and total_commands_processed all count from startup or the last CONFIG RESETSTAT. On an instance up for a month, a hit ratio that collapsed an hour ago is invisible: the month of good numbers averages it away. Take two samples a minute apart and subtract.

A fragmentation ratio below 1 is the worst number here

Above 1 means the allocator holds more than the data needs, which is normal slightly above 1 and worth attention above about 1.5. BELOW 1 means part of the dataset has been swapped to disk by the operating system. Redis is single threaded, so a page fault stalls every client, and latency becomes wildly unpredictable. This is a hardware or capacity problem, not a Redis tuning one.

Evicted and expired are different events

expired_keys counts keys whose TTL elapsed, which is intended. evicted_keys counts keys removed to stay under maxmemory, which for anything treated as a datastore is silent data loss. When a key has vanished and nobody knows why, these two counters are the only thing that distinguishes the causes.

rdb_last_bgsave_status is a write-availability signal

If it is not ok and stop-writes-on-bgsave-error is yes, which is the default, Redis refuses every write with MISCONF. The cause is usually a full disk or a permissions problem on dir, and the symptom the application sees is total write failure with an error that does not mention disks.

What this cannot see

It reads one snapshot of one instance. It cannot see trends, other nodes in a cluster, what the application is actually doing, or which keys are responsible for the memory. MEMORY DOCTOR and LATENCY DOCTOR on the server answer questions this cannot.