Redis Internals Explained: Event Loop, RDB vs AOF and Eviction

Every other client stops getting answers until that command finishes. Redis internals explain why: a single thread runs all commands in order, so a 300 millisecond command adds up to 300 milliseconds of wait for everyone queued behind it.

Picture a common setup. A food delivery app in Bengaluru keeps login sessions, rate-limit counters and a set of today's order IDs in one Redis server. Every night at 11 pm a cleanup script runs, and for a moment the whole app stalls. The setup is made up, but every timing in this guide was measured on a real Redis 8.10.2 server.

The script does two innocent-looking things. It runs KEYS with a pattern to find old sessions, and it deletes yesterday's order set, which holds 3 million (30 lakh) members. On a 2-core test machine, the first froze the server for about a third of a second. The second froze it for about two seconds.

This guide follows that one server. You will see why those two commands hurt, how Redis saves data to disk without stopping, and how it decides what to throw away when memory runs out.

You need six words. Each one gets a plain meaning here, and the rest of the guide uses only these names.

• Command: one request a client sends, such as GET user:42 or SET user:42 online. Redis replies to each command.
• Thread: a line of work inside a program that the CPU can run. A program with one main thread does one thing at a time on that thread.
• Event loop: the main thread's endless cycle. It asks the operating system which connections have data, runs the commands that arrived, sends replies and starts again.
• Fork: a Linux call that clones a running process. The clone, called the child, starts with the same memory as the parent.
• fsync: a call that forces data the operating system is holding in memory onto the disk. Until then, a power cut can lose it.
• Eviction: deleting keys on purpose when Redis reaches its memory limit, so new writes can fit.

Redis internals work like a single, very fast counter clerk. One main thread takes commands from many connections, runs each one to completion on data held in memory, and replies, one command at a time.

Because the data is in memory and most commands touch one key, each command usually takes microseconds. That speed is why one thread can keep up with a large number of clients. It is also why one slow command is so visible.

Think of a railway ticket counter with one clerk. Passengers are clients, and their requests are commands. The clerk is the main thread, and the clerk serves one request at a time from start to finish.

A normal request, one ticket, takes seconds, so the queue moves quickly. One passenger asking for 500 tickets holds up everyone behind them. That is KEYS on a big database. Where the picture breaks: Redis keeps no single queue in arrival order. Each turn of the loop serves whichever connections have data ready, and helpers can do the paperwork around requests.

On Linux, the waiting step uses epoll, a kernel feature that watches thousands of connections at once and reports which ones have data. Our 8.10.2 server reports this in INFO server as multiplexing_api:epoll.

Command execution runs on one main thread, and a few helper threads do side jobs. The official latency guide puts it this way: Redis is mostly single threaded and serves all requests using a single thread.

On our test server we listed the threads of the running process. With default settings there were four: the main thread plus three background threads named bio_close_file, bio_aof and bio_lazy_free. Bio is short for background I/O.

The useful rule is simple. For the core data types, anything a command does to your data, including searching, sorting and freeing memory, happens on the main thread. The exception is a command or setting that hands work off.

One scope note: Redis 8 also bundles a search and query engine whose release notes describe worker threads, set by search-workers. This guide covers the core data types only.

Anything that keeps the main thread busy for a long time blocks every client. In practice that means commands that touch many items, deleting huge values, long scripts and the SAVE command.

KEYS and other commands that touch every item

KEYS walks every key in the database to test the pattern. Its documentation gives the cost as O(N), meaning the time grows in step with N, the number of keys. It also says not to use KEYS in regular application code.

We loaded 2,000,000 keys with DEBUG POPULATE, a testing command that creates dummy keys. KEYS with a narrow pattern matched only 111 keys, yet took 312 to 367 milliseconds across three runs. A PING sent 50 milliseconds after KEYS started waited 263 to 317 milliseconds for its reply.

The fix is SCAN, which walks the keyspace in small steps and returns a cursor, a bookmark for the next step. With COUNT 1000, SCAN found the same 111 keys in 2,000 calls. The slowest PING between those calls took 0.10 milliseconds.

SCAN has two catches. The docs say a key may come back more than once, so your code must handle duplicates. COUNT is only a hint, and its default is 10. The latency guide names SORT, LREM and SUNION as other commands that can be slow on big collections. Check each command's documented time complexity before using it on big data.

A big DEL versus UNLINK

Now the surprise. DEL of a set with 3,000,000 members took 2,069 and 2,383 milliseconds on our 8.10.2 build. On the Ubuntu package of Redis 7.0.15 on the same machine, it took about 920 to 950 milliseconds. The two builds use different memory allocators, so treat both numbers as rough.

DEL is slow because the main thread must free every member, one memory allocation at a time. UNLINK removes the key from the keyspace at once and hands the freeing to the bio_lazy_free thread. UNLINK of the same set returned in 0.32 milliseconds, and once in 16 milliseconds.

The memory really is freed, just later. After the DEL and the UNLINK, used_memory fell from 278 MB to 1.19 MB within 1.5 seconds, so the background thread had finished. FLUSHALL ASYNC works the same way: 0.21 milliseconds for 2 million keys, against 1,087 milliseconds for FLUSHALL SYNC.

So the answer to the prediction: the DEL hurt about six times more than KEYS. Deleting is not free when a value holds millions of pieces.

Deletes you did not ask for

Redis also deletes values by itself. It does so when a key expires, when eviction removes a key, and when SET or RENAME overwrites an old value. The 8.10.2 configuration file says all of these free memory in a blocking way by default.

Each case has a switch: lazyfree-lazy-expire, lazyfree-lazy-eviction, lazyfree-lazy-server-del and lazyfree-lazy-user-del. All of them were set to no on our server. Setting lazyfree-lazy-user-del to yes made a plain DEL of the big set return in 0.20 milliseconds.

Long scripts and SAVE

A Lua script, a small program that Redis runs inside the server, also holds the main thread. We lowered busy-reply-threshold from its default of 5,000 ms to 500 ms and ran a script that looped for three seconds. Once the script ran past the threshold, another client's PING got a BUSY error instead of PONG.

SAVE writes the snapshot file on the main thread itself. On our 247 MB dataset it took 4,237 milliseconds, and a PING sent during it waited 4,190 milliseconds. BGSAVE does the same work in a child process, covered next.

# Commands slower than 10 ms (the default) are logged here
redis-cli SLOWLOG GET 5

# Record any event over 100 ms, then read the latest spikes
redis-cli CONFIG SET latency-monitor-threshold 100
redis-cli LATENCY LATEST

# Find keys without blocking: repeat with the returned cursor until it is 0
redis-cli SCAN 0 MATCH 'session:*' COUNT 1000

# Delete a huge value without freezing the server
redis-cli UNLINK orders:yesterday

What just happened? On our server, SLOWLOG GET showed each KEYS call with its time in microseconds, such as 366338, which is 366 milliseconds. LATENCY LATEST showed an event named command with its latest and worst spike in milliseconds.

Redis offers two ways to save data. RDB writes a full snapshot of memory to one compact file every so often. AOF, the append-only file, logs every write command so they can be replayed after a restart.

With no config file, our 8.10.2 server had RDB snapshots on with the rules 3600 1 300 100 60 10000. That means save after one hour if at least one key changed, after five minutes if 100 changed, or after one minute if 10,000 changed. AOF was off.

RDB: a snapshot written by a child process

BGSAVE forks the server. The child process has the same memory as the parent at that instant, so it writes a consistent snapshot while the parent keeps serving clients. In ps, the child appears as redis-rdb-bgsave.

The catch is the data written after the last snapshot. The official persistence page says that with RDB you should be ready to lose the latest minutes of data if Redis stops without a clean shutdown.

AOF: a log of every write

With AOF on, every write command is appended to a file in the same text format clients send. We turned AOF on, ran SET hello world, and found exactly that command at the end of the log file.

How much you can lose depends on appendfsync, the setting for how often Redis calls fsync. The default, everysec, calls it once a second on the bio_aof thread, so a crash can lose about one second of writes. The value always is safest and slowest, and no leaves flushing to the operating system.

The log keeps growing, so Redis rewrites it now and then in a forked child. Since Redis 7.0, AOF is split into parts in a folder: a base file, incremental files and a manifest that lists them. On our server the base file began with the bytes REDIS0015, because it is stored in RDB format by default.

The docs suggest using both if you want safety close to a traditional database. If losing a few minutes is fine, RDB alone is enough. If Redis only holds a cache you can rebuild, you can turn both off.

Fork itself is quick but not free, and memory can grow while the child runs. Both costs come from copy-on-write, a trick where parent and child share memory pages until one of them changes a page.

A page is the 4 KB block the operating system uses to manage memory. After fork, the kernel marks all pages as shared. When the parent writes to a key, the kernel first copies that whole page for the parent, so the child still sees the old version.

We measured both costs on 2 million keys using 247 MB. The fork took 10.7 milliseconds, shown in INFO stats as latest_fork_usec 10730, and BGSAVE replied in 15 milliseconds. The save itself took about four seconds.

With no writes during the save, rdb_last_cow_size was 0.79 MB. When a second client kept overwriting keys during the save, it rose to 53.8 MB. Those extra megabytes are pages the parent had to copy.

Fork time grows with memory size, because the kernel must copy the page table, the map from memory addresses to pages. The latency guide's example is a 24 GB instance needing a 48 MB page table. The persistence page warns that fork can stop Redis serving clients for milliseconds, or even a second on a very big dataset with a slow CPU.

The latency guide also says to disable transparent huge pages, a Linux feature that uses much bigger pages. With them on, a few thousand writes after fork can copy almost the whole process memory. Either way, a write-heavy server needs spare RAM during BGSAVE and AOF rewrites.

Redis checks memory before it runs a command, and if usage is over maxmemory it removes keys using the maxmemory-policy you chose. Out of the box, maxmemory is 0, meaning no limit, and the policy is noeviction.

With noeviction, writes fail once the limit is hit. Our test SET was refused with an error saying the command is not allowed when used memory is above maxmemory. GET kept working. That is the right choice for data you cannot lose, and the wrong one for a cache.

One trap: a volatile policy with no TTL keys behaves like noeviction. Our volatile-lru test with no expiring keys refused writes with the same error.

Approximated LRU: sample a few, keep a shortlist

LRU means least recently used. A perfect LRU would need a list of every key in access order, which costs memory and time. Redis instead samples a few random keys and evicts the one idle the longest.

The source makes it more precise. Each round samples maxmemory-samples keys, 5 by default and at most 64. Good candidates go into a pool of 16 keys, sorted by idle time, and the most idle key in the pool is evicted. The docs mention the pool but not its size; it is EVPOOL_SIZE in evict.c, undocumented as of 24 October 2026, so pin your version.

Does sampling pick well? We wrote 100,000 keys, waited two seconds, read 10,000 of them again, then set a limit and wrote 50,000 new keys. With samples of 3, 5 and 10, all 10,000 recently read keys survived. About 44 percent of the untouched old keys were evicted. The gap between hot and cold keys was large here, so this test cannot show the small accuracy gain the docs describe for 10 samples.

Idle time comes from a clock with one-second resolution, so OBJECT IDLETIME reports whole seconds. Keys touched within the same second look equally fresh to LRU.

LFU: a tiny counter that grows slowly

LFU means least frequently used. Each key has a 24-bit field that LRU uses for its clock. Under LFU, 8 bits hold a counter from 0 to 255, and 16 bits hold the last access time in minutes.

The counter grows by chance, and the chance shrinks as the counter grows. With the default lfu-log-factor of 10, the docs say it saturates at around a million hits. New keys start at 5, not 0, so they are not evicted before they get a chance. The counter drops by one for every lfu-decay-time minutes (default 1) that the key sits unused.

You can watch it with OBJECT FREQ under an LFU policy. A new key showed 5. After 10, 100, 1,000 and 10,000 reads, separate keys showed 7, 9, 19 and 48. The numbers vary run to run, because each increment is random.

For the delivery app, allkeys-lfu suits rate-limit counters and hot sessions that are read again and again. allkeys-lru suits data that is popular only for a while, like today's orders.

I/O threads take network work off the main thread, but commands still run one at a time on the main thread. The io-threads setting is 1 by default, which means no extra threads.

The Redis 8.0 release brought a new I/O threading design. Its announcement explains the split: the main thread assigns each client to an I/O thread, which reads and parses its commands. The main thread runs them and builds replies, and the I/O thread writes the replies back.

We started a server with io-threads 2. It gained exactly one extra thread, named io_thd_1, because the main thread counts as the first. INFO threads, a section added in 8.0, listed io_thread_0 and io_thread_1 with their client, read and write counts.

You cannot change it on a running server. CONFIG SET io-threads 4 failed with can't set immutable config, so it must go in the config file before startup. The 8.10.2 config file suggests it only on machines with 4 or more cores, leaving one core spare.

I/O threads help when the main thread spends its time on network reads and writes for many clients. They do nothing for a slow KEYS or a big DEL, because those run on the main thread either way.

Use the server's own counters before guessing. These steps take a few minutes and work on any recent Redis.

1. 1

   Read the slow log

   Run SLOWLOG GET 10. Each entry shows the command and its run time in microseconds. Anything above 10,000, the default threshold, is a candidate.

2. 2

   Turn on the latency monitor

   Run CONFIG SET latency-monitor-threshold 100, then LATENCY LATEST after a stall. Events such as command or fork show their latest and worst spike in milliseconds.

3. 3

   Check fork and copy-on-write

   Run INFO stats and INFO persistence. Look at latest_fork_usec, in microseconds, and rdb_last_cow_size or aof_last_cow_size, in bytes.

4. 4

   Check eviction and lazy free

   INFO stats shows evicted_keys. INFO memory shows lazyfree_pending_objects, the objects still waiting for the background thread.

5. 5

   Replace the offenders

   Swap KEYS for SCAN, DEL of big values for UNLINK, FLUSHALL for FLUSHALL ASYNC, and SAVE for BGSAVE. Then repeat step 1 to confirm.

Lead with the single-threaded execution model, then show you know what it costs and how to protect it. This frame fits in about two minutes.

1. 1

   State the model

   One main thread runs an event loop and executes commands one at a time on in-memory data. No locks are needed, and most commands take microseconds.

2. 2

   Name the risk

   Any command that touches many items blocks everyone: KEYS, big SORT or SUNION, a DEL of a huge value, long Lua scripts, SAVE.

3. 3

   Give the fixes

   SCAN instead of KEYS, UNLINK and the lazyfree settings for big deletes, BGSAVE instead of SAVE, and SLOWLOG plus the latency monitor to catch offenders.

4. 4

   Choose durability

   RDB snapshots for fast restarts and backups, AOF with everysec to lose about one second at most, or both. Mention fork and copy-on-write memory.

5. 5

   Size memory and eviction

   Set maxmemory with headroom for fork. Use allkeys-lru or allkeys-lfu for caches, noeviction for data you cannot lose, and explain sampling.

6. 6

   Scale out last

   I/O threads help network-heavy loads on multi-core machines. Beyond one main thread's CPU, shard keys across several Redis instances.