当 Redis 进程的 RSS 远大于 used_memory 时，很多人会直觉地认为只要删掉键值，内存就应该立刻下降。但实际情况是，Redis 使用 jemalloc 这类内存分配器管理堆内存，键删除后释放的空间不会马上归还给操作系统，而是被分配器缓存起来用于后续分配。这种机制能减少系统调用、提升分配效率，但代价是内存碎片和 RSS 虚高。MEMORY PURGE 就是针对这一问题的主动干预命令，它尝试让分配器把空闲内存页交还给操作系统。
要弄清楚 MEMORY PURGE 到底能做什么，必须先理解内存碎片和分配器的工作方式。本文会从底层行为、命令用法到生产实践逐层展开，同时给出可操作的监控与回收思路。
一、Redis 内存碎片从哪里来
Redis 的内存占用包含多个维度。INFO memory 里 used_memory 表示 Redis 内部实际保存数据使用的字节数，而操作系统视角的 RSS 则包含分配器额外占用的元数据、碎片和空闲页。当分配器频繁处理不同大小的对象时，内存会出现碎片化：一块连续内存被切分成小块后，即使总量足够，也可能无法满足大块分配需求，分配器只好向操作系统申请更多内存。
对于 jemalloc 来说，它按照 size class 管理内存，不同大小的对象放到不同的 arena 中。删除键后，对象占用的空间被回收到对应的 bin 或 run 里，但这些空间不会立即调用 munmap 归还内核。jemalloc 会保留一定数量的空闲页，以便下次快速复用。只有当空闲页数量超过阈值或触发某些条件时，才会真正释放。这就是 RSS 下降滞后于 used_memory 的根本原因。
# 查看内存指标 redis-cli INFO memory # 关注 used_memory_human、used_memory_rss_human、mem_fragmentation_ratio
除了分配器缓存，Redis 自身的过期键删除策略也会影响内存表现。惰性删除和定期删除虽然最终会释放键空间，但释放的内存同样进入分配器池子。因此，即使执行了 FLUSHDB 或大量 DEL，RSS 也可能长时间保持高位。
二、MEMORY PURGE 命令的作用与用法
MEMORY PURGE 是 Redis 4.0 引入的命令，作用是请求内存分配器释放它持有的空闲内存页。执行方式非常简单，在 redis-cli 中直接运行即可：
redis-cli MEMORY PURGE
这条命令没有参数，也没有返回值中的具体数字，它只是触发一次回收尝试。在底层，Redis 会调用 jemalloc 提供的 malloc_trim 或类似接口。以 jemalloc 为例，它会遍历 arena，尝试通过 madvise 或 munmap 把空闲页归还给操作系统。如果分配器本身没有多余的连续空闲页，或者内存被碎片化到无法合并的程度，命令执行后 RSS 可能毫无变化。
看到这里需要明确一点：MEMORY PURGE 不会删除任何键，也不会移动数据，它只影响分配器已经标记为空闲但尚未归还的内存。也就是说，如果 used_memory 本身就很高，RSS 也接近 used_memory，那么这条命令没有太多可释放的空间。它真正能发挥作用的是 used_memory 已经下降但 RSS 仍然偏高、碎片率较高的场景。
# 执行前后对比 redis-cli INFO memory | grep used_memory_rss_human redis-cli MEMORY PURGE redis-cli INFO memory | grep used_memory_rss_human
执行 MEMORY PURGE 可能会短暂阻塞 Redis 主线程，因为分配器需要扫描并整理内存页。虽然通常耗时在毫秒到几十毫秒级别，但在高并发写入或对延迟极敏感的业务中，建议在低峰期执行，并做好监控。
三、生产环境实践与效果验证
判断是否需要手动回收，可以看 mem_fragmentation_ratio 这个指标。它的计算方式是 used_memory_rss 除以 used_memory，比值越接近 1 说明内存使用越紧凑；如果超过 1.5 甚至更高，通常意味着存在明显碎片或分配器缓存。此时先别急着执行 PURGE，可以先用 MEMORY DOCTOR 获取诊断建议。
redis-cli MEMORY DOCTOR
有些情况下，执行 PURGE 后 RSS 会明显下降，比如刚完成一次大批量删除或 FLUSHDB，分配器里堆积了大量空闲页。但如果在业务高峰期执行，可能会导致请求延迟抖动，因为内存回收操作会与正常分配竞争锁资源。因此更稳妥的做法是：先评估碎片率，再选择低峰窗口执行，并提前通知相关人员。
除了手动 PURGE，Redis 还提供了主动碎片整理功能 activedefrag。它会在后台自动检测并整理内存碎片，无需人工执行命令。可以通过配置开启：
# redis.conf 配置示例 activedefrag yes active-defrag-ignore-bytes 100mb active-defrag-threshold-lower 10 active-defrag-threshold-upper 100
这种方式对业务侵入较小，但在极端碎片情况下也可能不够彻底。必要时可以组合使用：先开启 activedefrag 自动整理，再在低峰期执行 MEMORY PURGE 作为补充。
四、常见误区与边界
第一个误区是认为 MEMORY PURGE 可以回收所有被删除键的内存。实际上它只回收分配器空闲页，对于仍然被 Redis 内部结构引用的内存、复制缓冲区、客户端输出缓冲区等，都不会产生影响。例如主从同步期间积压的 replication backlog，即使执行 PURGE 也不会被释放。
第二个误区是把它当成解决内存不足的万能命令。如果 used_memory 已经接近 maxmemory，说明数据本身占用过大，此时 PURGE 无法凭空变出可用内存，应该考虑数据淘汰策略、分片或扩容。第三个误区是频繁执行 PURGE 以为能保持低 RSS，但每次执行都可能带来延迟，反而得不偿失。
最后，不同 Redis 版本和不同内存分配器对 PURGE 的支持程度不一样。如果编译时使用 libc 而非 jemalloc，效果可能非常有限。可以通过 MEMORY MALLOC-STATS 查看分配器内部统计，确认空闲页数量。只有真正理解了内存去向，才能判断 PURGE 是否值得执行。
Redis内存回收MEMORY PURGE手动释放内存修改时间：2026-09-25 21:27:39