Spotting a bad Redis usage

Redis Course · lesson 14 of 19 · 5 min read

Most Redis incidents are one of four mistakes, and all four are visible from redis-cli in a minute.

Open this lesson in the learning hub

Key points

  • KEYS pattern is O(N) over the entire keyspace and blocks the single thread until it finishes - never run it in production.
  • SCAN walks the keyspace with a cursor in small batches; it may return duplicates but it never blocks.
  • A value of several megabytes blocks the server while it is serialised, so find them with redis-cli --bigkeys.
  • DEL on a huge collection blocks too; UNLINK (Redis 4.0) frees the memory on a background thread instead.
  • Keys written without a TTL never leave, which is how a cache reaches maxmemory and starts refusing or evicting writes.
  • The slow log records commands over slowlog-log-slower-than, which defaults to 10000 microseconds, or 10 ms.

Example

$ redis-cli --bigkeys
[00.00%] Biggest hash   found so far "session:blob" with 240118 fields

$ redis-cli MEMORY USAGE product:991
(integer) 3145944

$ redis-cli SLOWLOG GET 2
1) 1) (integer) 14
   2) (integer) 1722688201
   3) (integer) 4210330          # microseconds -> 4.2 seconds blocked
   4) 1) "KEYS"
      2) "session:*"

$ redis-cli --scan --pattern "session:*" | head
$ redis-cli INFO keyspace
db0:keys=8421003,expires=1204,avg_ttl=0   # only 1204 keys have a TTL

No KEYS, no giant values, no unbounded keys without TTLs - and check --bigkeys and the slow log before blaming Redis.

Redis from Spring Boot Where the memory actually goes

This is a reading copy. The full lesson — with the visual explainer, the interactive lab and a Run button for the code — lives in the Redis Course course, and every lesson in it is listed on the Redis Course contents page.