Redis内存释放慢？调整hz参数提升清理效率

Redis内存释放延迟并非内存泄漏，而是源于其惰性删除与定期扫描相结合的过期键清理机制，其中关键参数`hz`直接决定后台扫描频率：默认值10导致大实例下清理严重滞后，适当调高至100可显著加速内存回收，但超过100后收益递减且易引发CPU飙升；调整前需严谨验证是否真由过期扫描瓶颈导致，并排查内存碎片、maxmemory配置及集中过期风暴等根本原因，生产环境务必通过`CONFIG SET`热更新+实时监控的方式安全迭代，避免盲目优化反伤性能。

为什么DEL或EXPIRE后内存没立刻下降

Redis 的内存释放不是即时同步的，尤其在大量 key 过期或被删除时，used_memory 可能长时间不回落。这不是内存泄漏，而是因为 Redis 采用惰性+定期双机制清理过期 key：惰性清理只在访问 key 时检查过期，而定期清理由后台周期任务执行，其频率受 hz 参数控制。

hz 参数如何影响过期键扫描速度

hz 决定了 Redis 每秒执行多少次定时任务（默认 10），包括过期 key 扫描、LRU/LFU 淘汰候选池更新、AOF 缓冲刷写等。值越大，扫描越频繁，过期 key 被及时发现并释放的概率越高；但也会增加 CPU 占用，尤其在高负载实例中可能挤占命令处理时间。

• 默认 hz 10：每 100ms 做一次扫描，每次最多检查 20 个数据库中的 key，且每个库只随机抽样 20 个 key —— 在大实例（如 100w+ 过期 key）下，清理严重滞后
• 调高到 hz 100：扫描间隔缩短至 10ms，抽样频次和总量显著提升，能更快触达待淘汰 key
• 但注意：hz 不是线性加速器 —— 超过 100 后收益递减，且可能使 redis-server 进程 CPU 使用率持续高于 30%

调整 hz 前必须确认的三件事

盲目调高 hz 可能引发新问题，需先验证当前瓶颈是否真出在过期扫描上：

• 先查 INFO stats 中的 expired_keys 和 evicted_keys 是否持续增长，若两者长期为 0，说明根本没触发淘汰逻辑，调 hz 无意义
• 确认 maxmemory 已启用且接近上限 —— 若内存充足，Redis 根本不会主动驱逐，hz 对淘汰无影响
• 检查 INFO memory 中的 mem_fragmentation_ratio，若 >1.5 且 used_memory_rss 远高于 used_memory，说明内存碎片严重，此时调 hz 不解决释放缓慢，反而加重碎片分配压力

生产环境调整 hz 的安全操作方式

不建议直接修改配置文件重启，应先热更新验证效果：

• 临时生效（立即生效，重启后失效）：CONFIG SET hz 100
• 观察 5 分钟内 INFO stats 中 expired_keys 的增量速率是否明显加快，同时监控 instantaneous_ops_per_sec 是否下跌超过 15%
• 若有效且无副作用，再写入 redis.conf 并 CONFIG REWRITE 持久化；否则回退：CONFIG SET hz 10
• 特别注意：集群模式下，每个节点需单独设置，hz 不同步，也不能通过 CONFIG GET/SET 跨节点批量操作

真正卡住内存释放的，往往不是 hz 太低，而是 key 设计不合理（比如批量写入百万级 EXPIREAT 时间戳相近的 key）—— 这种集中过期风暴，再高的 hz 也救不了，得从上游控制过期时间离散化。

好了，本文到此结束，带大家了解了《Redis内存释放慢？调整hz参数提升清理效率》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！