WIUNIX ACADEMY
Redis latency and memory pressure: diagnose eviction before changing policy
Page 2 of 2. Review the earlier steps and prerequisites before continuing.
YOUR SYSTEM. YOUR STEPS.
Where are you working?
Choose your OS and version. The prerequisites, commands and troubleshooting follow your environment.
USE YOUR OWN VALUES
Configure this tutorial
Set the example values for your environment; related explanations and copy panels update together. Never enter passwords, private keys or tokens. Values stay in this tab and are not sent to the server or share links. Check actual DNS, certificates and network policy before running commands.
Different IP addresses, domains or ports? Open the settings below, change the values and select “Apply to tutorial”, then copy the updated commands.
Set values for my environment2 editable values
Classify the workload before changing eviction
A cache can tolerate selected key loss only if the source of truth and miss path can absorb it. A queue, lock or durable record cannot inherit an allkeys policy merely because a cache tutorial uses it. Noeviction returns write errors when memory is exhausted; it does not prevent host OOM. Volatile policies select only expiring keys and can run out of eligible keys. A nonzero eviction rate is not automatically a failure: correlate it with misses, origin load, response latency and business correctness.
LET’S BUILD
Inspect slow-command metadata without printing arguments
SLOWLOG entries can contain customer keys, values and client identities. This local filter prints only entry ID, Unix timestamp, duration in microseconds and the command verb. Keep the terminal private; filtering output does not make access itself non-sensitive. A slow log can be empty because its threshold is high or collection is disabled; absence of entries is not proof of a healthy network or fast application.
Existing Redis host, authorized observer account
redis-cli -s '/run/redis/redis.sock' --user 'observer' --askpass --json SLOWLOG GET 20 | python3 -c 'import json,sys; rows=json.load(sys.stdin); [(print({"id":r[0],"unix_time":r[1],"duration_us":r[2],"verb":r[3][0] if r[3] else ""})) for r in rows]'Only redacted command metadata is printed; duration units are explicit.
LET’S BUILD
Read existing latency events before enabling more collection
LATENCY LATEST/DOCTOR depends on the configured latency monitor threshold. If disabled, this guide does not change it automatically; enabling collection requires an owning bounded decision and a recorded old value. Correlate event timestamps with eviction, fork, disk/AOF and workload changes. Commandstats adds execution/failure counts but does not measure application queue time.
Existing Redis host, authorized observer account
redis-cli -s '/run/redis/redis.sock' --user 'observer' --askpass LATENCY LATEST
redis-cli -s '/run/redis/redis.sock' --user 'observer' --askpass LATENCY DOCTOR
redis-cli -s '/run/redis/redis.sock' --user 'observer' --askpass INFO commandstatsExisting events support or refute a time-correlated hypothesis; disabled collection is recorded honestly.
LET’S BUILD
Take an optional short local PING sample
Only in an approved observation window, run this ten-second local socket probe. Redis CLI sends repeated PINGs, so it is a small additional load, not a passive measurement. The reported milliseconds include this client’s scheduling and socket path, not the application network. Timeout exit124 is expected at the boundary. Compare with the application’s existing connection/queue/response spans; do not add broad MONITOR capture or keyspace scans during an incident.
Existing Redis host, authorized observer account
timeout 10s redis-cli -s '/run/redis/redis.sock' --user 'observer' --askpass --latencyA bounded local baseline is distinguished from application end-to-end latency.
Choose a reversible response from evidence
If client latency rises with low server execution time, investigate client pool wait, connection churn and network first. If evictions and misses rise together, budget cache capacity or key lifetime only after checking the origin can survive misses. If RSS/host pressure rises around persistence work, plan headroom rather than removing durability. If slow command execution dominates, reproduce its data shape safely on staging. No blanket threshold or eviction policy fits every workload.
End observation and keep a minimal evidence record
The probe ends by timeout; this guide changed no server setting and needs no rollback command. Retain interval boundaries, run_id, counter deltas, memory headroom, redacted slow-command metadata and one proposed staged action. For any later approved configuration change record the exact old value, persistence effect and rollback before applying it. Do not flush databases, reset counters or restart Redis merely to make graphs look clean.
GO TO THE SOURCE
Official references
Each environment states how it was reviewed. A documentation review does not claim a hands-on test of every version.
- Redis: latency diagnosis
- Redis: eviction policies
- Redis: INFO counters
- Redis: SLOWLOG GET
- Redis: MEMORY STATS
- Compatibility and installation path: Redis / Linux
- Compatibility and installation path: Redis / APT
- Compatibility and installation path: Redis / RPM
- Red Hat: diagnosing SELinux access denials
- Red Hat: firewalld inspection and management
KEEP LEARNING