Redis memory and latency investigation cheat sheet

Compare Redis identity, memory pressure, eviction counters, client connections and slow-command evidence without scanning the keyspace.

Redis CLI against a permitted Redis endpoint. Examples use a local endpoint on 127.0.0.1:6379; ACL permissions and managed-service command support vary.

Updated 2026-11-02 · Redis · 6 min read

Command	What it does
`redis-cli -h 127.0.0.1 -p 6379 PING`	Test the selected Redis endpoint
`redis-cli -h 127.0.0.1 -p 6379 INFO server`	Identify the server and uptime
`redis-cli -h 127.0.0.1 -p 6379 INFO memory`	Inspect memory use and configured limits
`redis-cli -h 127.0.0.1 -p 6379 INFO stats`	Compare eviction and cache counters
`redis-cli -h 127.0.0.1 -p 6379 INFO clients`	Inspect connection pressure
`redis-cli -h 127.0.0.1 -p 6379 SLOWLOG GET 10`	Read a bounded slow-command sample

Walkthrough

Use an existing authenticated session or approved credential mechanism. Adapt host, TLS and authentication options to your environment; do not place passwords in shared command lines. No key writes, KEYS, MONITOR or configuration changes are used.

Step 1: Test the selected Redis endpoint

redis-cli -h 127.0.0.1 -p 6379 PING

A PONG confirms the server answered this command on this connection. It does not prove application authorization, cache-hit behavior or acceptable latency under load. An authentication or ACL error is different from a connection timeout.

Step 2: Identify the server and uptime

redis-cli -h 127.0.0.1 -p 6379 INFO server

Record version, server mode and uptime to correlate a restart with the incident. In clustered or replicated deployments, one endpoint does not represent all nodes; confirm which node the application actually uses.

Step 3: Inspect memory use and configured limits

redis-cli -h 127.0.0.1 -p 6379 INFO memory

Compare used_memory, used_memory_rss, maxmemory and maxmemory_policy. RSS and allocator memory measure different things. A zero maxmemory value is not evidence of unlimited physical RAM; host or container limits can still apply.

Step 4: Compare eviction and cache counters

redis-cli -h 127.0.0.1 -p 6379 INFO stats

Capture evicted_keys, keyspace_hits and keyspace_misses twice with timestamps. These are cumulative counters, so a historical nonzero value does not prove an active incident. Compare deltas and the workload mix, not only totals.

Step 5: Inspect connection pressure

redis-cli -h 127.0.0.1 -p 6379 INFO clients

Compare connected_clients and blocked_clients with normal operation and application connection-pool settings. Blocked clients may be legitimate consumers using blocking commands; they are not automatically evidence of a hung server.

Step 6: Read a bounded slow-command sample

redis-cli -h 127.0.0.1 -p 6379 SLOWLOG GET 10

Inspect execution time and command shape. Slowlog measures command execution rather than all client/network waiting and contains only retained entries above its configured threshold. Arguments can expose data, so redact them before sharing.

WORKED INCIDENT

Practical case: Cache misses rise during a memory-pressure incident

Fictional teaching scenario; observations are examples, not captured production output.

Situation

An application reports more backend reads and slower responses while Redis remains reachable.

Investigation sequence

1. Test the selected Redis endpoint

redis-cli -h 127.0.0.1 -p 6379 PING

Confirm the application endpoint answers; availability alone does not establish useful cache performance.

2. Inspect memory use and configured limits

redis-cli -h 127.0.0.1 -p 6379 INFO memory

Compare memory with maxmemory and record the configured eviction policy.

3. Compare eviction and cache counters

redis-cli -h 127.0.0.1 -p 6379 INFO stats

Collect two counter samples. In this example evicted_keys and keyspace_misses both increase during the incident.

4. Read a bounded slow-command sample

redis-cli -h 127.0.0.1 -p 6379 SLOWLOG GET 10

Check retained slow commands as a separate signal; their absence does not rule out network or client delays.

Example findings

Illustrative findings: PONG succeeds; used_memory is near maxmemory; evicted_keys rises between samples; the workload has increasing misses.

Interpret the findings

The samples support active eviction under memory pressure. They do not establish whether sizing, TTL choices or workload growth caused it, and cache misses can have other explanations.

Verify the outcome

After the owner applies an approved sizing or retention adjustment, compare the same counter deltas under similar load. Confirm application hit behavior, latency and host memory headroom.

Escalation handoff

Provide the node identity, memory policy, timestamped counter deltas and redacted slow-command shapes to the cache/application owner. Avoid dumping keys or values.