GopherForgeA WORKBENCH FOR GO

Around Go: MongoDB and Redis · 3 MIN READ

Redis under load: hot keys, memory pressure and ambiguous retries

Inspect server latency and memory while bounding client work and retry amplification.

Redis command latency can rise because of expensive commands, a hot key, big values, persistence work, network delay or waiting in the client. A low average hides queues and timeout bursts. Correlate request errors with server and client evidence before increasing goroutines or connection limits.

Around Go: data stores · A MAP OF THE IDEA

  1. Client wait
  2. Command work
  3. Memory and persistence
  4. Bounded recovery

Useful when

  • Inspect server latency and memory while bounding client work and retry amplification.

Watch out

  • SLOWLOG measures server execution. Callers can still wait for a client connection or network response; retries can then amplify load or repeat an ambiguous write.

Implementation & operation cost: Latency and eviction policies trade memory, availability and persistence work; client concurrency cannot remove a hot-key bottleneck.

01

Use focused observation commands

In an authorized development environment, inspect memory, command statistics and recent slow commands. SLOWLOG measures server command execution, not every network or client-pool delay. Keep raw keys and command arguments out of broadly shared diagnostics when they may contain user data.

bash
redis-cli INFO memory
redis-cli INFO stats
redis-cli INFO commandstats
redis-cli SLOWLOG GET 10
redis-cli LATENCY LATEST
Read the code

Metrics and latency monitoring availability depend on server configuration and permissions. Compare the same time window with client pool wait and request p99; a quiet SLOWLOG does not prove that callers were fast.

02

Scan incrementally and cap batch work

KEYS can block while traversing a large keyspace. SCAN divides that work into cursor-driven steps, but it is not a snapshot, COUNT is a hint and keys may appear more than once. Keep downstream handling idempotent and avoid moving all returned keys into one giant slice.

bash
redis-cli SCAN 0 MATCH 'demo:*' COUNT 100
# Continue with the returned cursor until it is 0.
redis-cli MEMORY USAGE demo:product:42
Read the code

A single SCAN call is not a complete inventory. Even incremental maintenance needs rate and time budgets; do not run an unbounded sweep simply because each individual command looks small.

03

Define storage and retry guarantees

Eviction policy and persistence determine whether a value can disappear and what survives failure. Replication is not automatically synchronous durability. Retrying INCR after a lost response may apply the effect twice; use an operation identifier and a suitable atomic protocol when duplicate effects are unacceptable. Bound retries within one deadline and measure recovery after overload.

TAKE THIS WITH YOU

Separate client wait from server execution, keep maintenance incremental and design for eviction, persistence and ambiguous write outcomes. More concurrency is not a repair for a hot bottleneck.

Check your understanding

Why can callers time out while SLOWLOG shows no slow commands?

Go to the source

Progress stays in this browser. No account needed.