Redis / Editorial solution guide

Diagnose slow requests, memory and command cost

Separate client/network delay from Redis execution, large work and memory pressure. Choose a narrow evidence-based remedy without scans, load tests or universal tuning.

About 4 min readContent reviewed

Read-only knowledge base · No public comments

Recognize the symptoms

Tail latency grows, requests time out, memory rises or writes report OOM. A small SLOWLOG duration can coexist with a slow application, and Redis command work depends on the selected structure and input size. Record the actual command, argument and reply sizes, topology, client pool behavior and incident times.

Understand the likely causes

  • Possible causes include pool queueing, connection/TLS setup, network transfer, large key operations, blocking scripts, oversized pipelines, persistence/copy-on-write peaks, hot slots or memory-policy mismatch. maxmemory eviction accounting is not the whole process resident-memory ceiling. A large backlog or payload can cause both latency and memory symptoms, so investigate correlated evidence rather than assigning every timeout to the server CPU.

Define comparable measurements before a change

Capture repeated end-to-end latency with a stated measurement boundary and representative request shapes. Preserve business result correctness and distinguish a warm cache from a cold source reload. Compare the same time window across client, server and platform metrics. Do not run a load generator, broad key scan or configuration experiment against a configured service to recreate the issue. An approved isolated calculation or existing operational evidence can guide the next question without exposing data or adding uncontrolled pressure.

Use bounded metrics and understand their scope

INFO sections and a limited slow-log sample are complementary, not interchangeable. Slow-log time describes server execution rather than full client/network waiting, and logged arguments can be sensitive. Memory metrics can include logical data, allocation and separately reported buffers, so use the deployed version’s definitions. No values are fabricated by the examples and no logging is enabled. A managed service may restrict commands or expose a dashboard; use its supported authorized observation path rather than granting administration access for convenience.

redis Non-runnable limited diagnostic sample 
INFO memory
INFO commandstats
SLOWLOG GET 5

Inspect privately under the approved operational process. No slow operation, measured duration or safe memory threshold is asserted.

Connect command work to a justified remedy

Check whether a command traverses a large list, set, hash or result, whether a script is bounded, and whether a pipeline queues too many reply bytes. Do not replace KEYS with an unbounded SCAN loop and call the entire task free: SCAN has incremental guarantees, can repeat keys and is not a frozen snapshot. For OOM, inspect policy and eligible keys; volatile policies may lack candidates when keys have no TTL. Avoid enabling arbitrary eviction for authoritative work or disabling persistence merely to lower a resource graph.

Use a declared model to avoid a wrong diagnosis

This local latency budget gives most hypothetical time to the pool and network, demonstrating why server execution evidence alone can be insufficient. The values are invented units, not Redis timings or a production tuning formula. A real diagnosis needs independent observations and consistent clocks without double-counting overlapping intervals. Address the component supported by the evidence: bound clients and batches for queueing, reduce justified expensive work, or review capacity and persistence peaks. Increasing every timeout or pool size can conceal saturation and amplify demand rather than solve the cause.

python Offline hypothetical latency budget 
budget = {'pool': 45, 'network': 25, 'command': 2, 'decode': 3}
assert sum(budget.values()) == 75
assert budget['pool'] + budget['network'] == 70
assert budget['command'] < budget['pool']

The model has 75 total units and 70 in pool plus network. It measures no service and changes no resource limit.

Verify the fix

Compare the same required results, latency percentiles, throughput, pending work, memory, evictions and write rejection after a reviewed change. Include source reload and recovery behavior where relevant. Record the observed bottleneck resolved and remaining uncertainty; a lower graph or one cached fast command does not establish complete performance or correctness.

Keep it from recurring

  • Budget connections, batch bytes and bounded data structures from measured workload. Track client and server latency separately, keep diagnostic data private and test persistence/failover peaks through the approved process. Version monitoring interpretations and avoid universal numeric recommendations copied from another deployment.

Official references