I found that when deleting a large string through the unlink command, it is still deleted synchronously, which is very time-consuming and causes the main thread to be blocked, affecting subsequent requests.

I encountered a real problem: we stored some large bitmaps in redis. When deleting such keys, the redis server CPU was high and accompanied by some timeout problems.

I found that the lazyfreeGetFreeEffort function did not process the string type, and then I found this PR: https://github.com/redis/redis/pull/8365

The author of this PR also mentioned that when the string length is greater than a certain value, deletion is very time-consuming.

So, should we reconsider allowing the lazyfreeGetFreeEffort function to support large strings?

8365

Comment From: sundb

@Orlion thanks, what the size of your bitmap? which allocation did you use? jemalloc or glibc?

Comment From: Orlion

@Orlion thanks, what the size of your bitmap? which allocation did you use? jemalloc or glibc?

The size of the bitmap is about 4MB, and we use jemalloc.

Comment From: sundb

@Orlion how do you know it's caused by free and not by allocate? in theory, free is quite fast, the memory is not freed as soon as the api calling, but it is placed in to the queue waiting for some time to reclaim to kernel.

Comment From: Orlion

@Orlion how do you know it's caused by free and not by allocate? in theory, free is quite fast, the memory is not freed as soon as the api calling, but it is placed in to the queue waiting for some time to reclaim to kernel.

Yes, maybe you are right. I repeated the experiment and found that deleting the key did not cause a significant fluctuation in CPU usage. It may be due to other reasons. If I can reproduce it again, I will discuss this issue with you again. Now thank you for your answer.