Redis big keys
One oversized hash, list, or sorted set can dominate memory and turn a single HGETALL / SMEMBERS / unbounded LRANGE into a latency event for every client. Aggregate used_memory can look “fine” while P99 explodes.
Why big keys cause Redis high latency
Command execution is single-threaded. An O(N) touch on a giant key queues everyone else behind it — even when PING still looks healthy.
Replication and persistence cost scale with key size; big keys make failovers and rewrites more expensive.
Splitting structures, paginating reads, or moving blobs out of Redis usually beats “just add RAM.”
How to find large Redis keys safely
redis-cli --bigkeys and MEMORY USAGE use incremental SCAN — still respect load. Baltan’s agent rate-limits SCAN and reports names and sizes only.
Watch SLOWLOG for HGETALL, SMEMBERS, LRANGE 0 -1, SORT, and wide ZRANGE* — often the symptom of a big key, not a “slow network.”
Never use MONITOR to hunt big keys in production; it streams every command and can cut throughput roughly in half.
What Baltan shows
Largest sampled keys by bytes, tied to findings when they correlate with latency or memory pressure.
Dashboard actions tell you what to inspect in your app next — without browsing values inside Baltan.