Lesson 2

Who removes an expired key

A key that expires at 10:00:00 does not leave memory at 10:00:00. It leaves when something touches it, or when the background cycle happens to draw it into a sample. In between, the key still occupies memory and is still counted by DBSIZE, even though every read behaves as if it were gone.

Two deletion mechanisms

• Lazy deletion. Any command that looks a key up checks its expiry first. An expired key is deleted right there, and the command answers as if the key never existed. This mechanism only ever removes the keys a command actually touches.
• The active cycle. On each serverCron tick, Redis draws a random sample from the set of keys that carry an expiry, deletes the ones that are past due, and repeats if the expired fraction of the sample is still high. No client has to be involved.

Both increment expired_keys in INFO stats, so that counter is a combined total and cannot tell you which mechanism did the work. The way to separate them is to switch the active cycle off entirely.

Switching off the cycle to separate them

DEBUG SET-ACTIVE-EXPIRE 0 disables the cycle. Since Redis 7, DEBUG is locked down by default, so the first attempt returns:

ERR DEBUG command not allowed. If the enable-debug-command option is set
to "local", you can run it from a local connection, otherwise you need to
set this option in the configuration file, and then restart the server.

This is the easiest place in the whole lesson to measure the wrong thing. The DEBUG command fails but the rig carries on, so the first table looks as though the cycle had been switched off when it was still running — and every number in that table is meaningless. The container has to be restarted with the option:

docker run -d --name rdlab -p 8088:6379 redis:7-alpine \
  redis-server --enable-debug-command local

docker exec rdlab redis-cli DEBUG SET-ACTIVE-EXPIRE 0
# OK

With the cycle off, build 300 keys with a 200 ms TTL in a single EVAL — so they all expire at the same instant — plus one key with no expiry, then wait a second:

DBSIZE        → 301
KEYS *        → 1 key
expired_keys  → 0

Nine commands, each measured alone

Every row below is a fresh rebuild of the same state — 300 keys that expired 800 ms ago plus one live key, active cycle off — followed by exactly one command:

How fast the active cycle really is

Switch the cycle back on, build 20,000 keys with a 400 ms TTL in one EVAL, then read DBSIZE every 100 ms from the moment they expire, with no client touching a key:

20,000 keys that expire at the same instant are cleared within about 200 ms, with nobody reading them. The first row is also instructive: DBSIZE read 366 while expired_keys had already reached 19,634 — the two commands ran a few milliseconds apart, and in that gap the cycle had removed nearly everything. The cycle is not slow; what makes people think it is slow is a moment like that 0 ms row.

Because the cycle samples at random, how long cleanup takes depends on the fraction of expired keys among the keys that carry an expiry. When that fraction is tiny — a handful of expired keys among a million with long TTLs — a single key can sit in memory for a long time, and DBSIZE will keep counting it.

The lab

Set the number of live keys and expired keys, then pick a command. The active cycle is treated as switched off, so only the command you run can remove a key. The algorithm was checked against the eight measured rows above; RANDOMKEY is not in the lab because it is random.

A TTL belongs to the key, not to the value

The second common question about expiry is which commands lose the TTL. The table below is measured by running SET k 1 EX 100, then exactly one command, then reading TTL k:

Check yourself