# Redis lazy freeing reduces blocking from large DEL operations

DevFeed: [Redis lazy freeing reduces blocking from large DEL operations](<https://devfeed.tech/articles/lazy-redis-is-better-redis-20684.md>)

Original publisher: [Read original article](<http://antirez.com/news/93>)

Published: 2015-09-26T07:56:32Z

Content type: opinion

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [Server](<https://devfeed.tech/topics/server.md>)

Tags: [asynchronous](<https://devfeed.tech/tags/asynchronous.md>), [blocking](<https://devfeed.tech/tags/blocking.md>), [latency](<https://devfeed.tech/tags/latency.md>), [redis](<https://devfeed.tech/tags/redis.md>), [server](<https://devfeed.tech/tags/server.md>)

## AI overview

The article discusses Redis's lazy freeing feature, which addresses blocking DEL operations when large keys are deleted. It explains incrementally freeing allocations to reduce latency spikes while preserving roughly the same CPU cost.

## Source excerpt

Everybody knows Redis is single threaded. The best informed ones will tell you that, actually, Redis is *kinda* single threaded, since there are threads in order to perform certain slow operations on disk. So far threaded operations were so focused on I/O that our small library to perform asynchronous tasks on a different thread was called bio.c: Background I/O, basically. However some time ago I opened an issue where I promised a new Redis feature that many wanted, me included, called "lazy free". The original issue is here: https://github.com/antirez/redis/issues/1748. The gist of the issue is that Redis DEL operations are normally blocking, so if you send Redis "DEL mykey" and your key happens to have 50 million objects, the server will block for seconds without serving anything in the meantime. Historically this was accepted mostly as a side effect of the Redis design, but is a limit in certain use cases. DEL is not the only blocking command, but is a special one, since usually we say: Redis is very fast as long as you use O(1) and O(log_N) commands. You are free to use O(N) commands but be aware that it's not the case we optimized for, be prepared for latency spikes. This sounds reasonable, but at the same time, even objects created with fast operations need to be deleted. And in this case, Redis blocks. The first attempt -- In a single-threaded server the easy way to make operations non-blocking is to do things incrementally instead of stopping the world. So if there is to free a 1 million allocations, instead of blocking everything in a for() loop, we can free 1000 elements each millisecond, for example. The CPU time used is the same, or a bit more, since there is more logic, but the latency from the point of view of the user is ways better. Maybe those cycles to free 1000 elements per millisecond were not even used. Avoiding to block for seconds is the key here. This is how many things inside Redis work: LRU eviction and keys expires are two obvious examples,