首页/数据/Redis 进阶速查/lazyfree-lazy-server-del:内部删除异步
内存与管理99 条

lazyfree-lazy-server-del:内部删除异步

lazyfree-lazy-server-del yes 使服务端内部触发的删除(如字典扩容、类型转换、集合运算中间结果)异步释放内存。

Redis 进阶速查数据更新于 2026-10-13

lazyfree-lazy-server-del 是什么

lazyfree-lazy-server-del 是默认 no 的配置项,管的是服务端内部触发的删除:用 SET 覆盖一个已有对象、RENAME 覆盖目标键、类型转换时丢弃旧值、集合运算产生的大中间结果等。开启后这些释放走后台线程,减少那些在命令参数里看不见的延迟毛刺。

基本信息

配置项lazyfree-lazy-server-del
默认值no
覆盖范围服务端内部删除路径(非客户端显式 DEL)
起始版本Redis 4.0
观测字段INFO stats 的 lazyfree_pending_objects / lazyfreed_objects

典型使用场景

  • 慢日志里出现低频但耗时可观的覆盖写或改名操作
  • 偶发延迟毛刺找不到对应命令,怀疑来自内部释放
  • 大键被频繁整表覆盖写(例如定时全量刷新缓存)
  • 集合运算产生大中间结果,运算结束瞬间出现停顿
  • 变更前后用延迟指标做对照,验证是否真的有效

变更与对照

变更与对照
redis-cli LATENCY RESET                                # 变更前重置采样,得到干净基线
redis-cli CONFIG SET lazyfree-lazy-server-del yes      # 打开内部删除异步
redis-cli SLOWLOG RESET                                # 同步清空慢日志窗口
# ... 让业务跑一段时间后回看
redis-cli LATENCY LATEST                               # 有没有新的事件峰
redis-cli SLOWLOG GET 10                               # 覆盖写、改名类命令是否变快
redis-cli INFO stats | grep lazyfree

哪些删除受它控制

删除来源触发方式是否受该开关控制
显式删除客户端执行 DEL / UNLINKUNLINK 本就异步,DEL 由 lazyfree-lazy-user-del 控制
覆盖写SET 覆盖已有键、旧值被丢弃属于服务端内部删除
改名覆盖RENAME 把目标键的旧值丢弃属于服务端内部删除
过期与淘汰到期删除、maxmemory 淘汰由 lazyfree-lazy-expire / -eviction 分别控制
这条路径的收益最难度量:内部删除不出现在命令参数里,只能靠延迟指标的前后对比来判断,建议先在压测环境验证再上生产。

适用性判断

  • 实例中存在体积明显偏大的对象,例如大 Hash、大 List、超长 String
  • 慢日志显示覆盖写或改名类命令的耗时占比偏高
  • 延迟毛刺的时间点与全量刷新、定时换表等业务动作吻合
  • 实例 CPU 仍有余量,能承受后台线程的资源抢占
  • 已经确认毛刺不是持久化、网络或系统层所致
与 UNLINK 的分工要分清:客户端侧的删除改用 UNLINK 就已异步,本开关解决的是应用无法显式控制的那部分内部释放。

易错点

  • 把它当作解决所有延迟问题的开关,但根因可能来自持久化、网络或系统层
  • 内部删除的收益难以直接度量,缺少前后对比就断言有效
  • 只改运行时配置没写回配置文件,重启后悄悄失效
  • 与 UNLINK 混淆,误以为开启后客户端的 DEL 也会异步(那是 lazyfree-lazy-user-del 的事)

数据来源与参考

  • Redis 官方文档:lazyfree server-del 说明
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌