Redis内存碎片是运维过程中经常被忽视却又影响深远的问题。典型的表现是：通过INFO memory命令查看时，发现used_memory只有2GB，而used_memory_rss却达到了5GB，mem_fragmentation_ratio碎片率超过2.5。这意味着操作系统实际分配给Redis的物理内存远大于业务数据本身需要的空间，严重时甚至触发OOM或者被系统swap拖垮性能。要解决这个问题，首先需要理解碎片是怎么产生的，再选择合适的整理手段。
一、内存碎片是如何产生的
Redis本身并不直接向操作系统申请内存，而是通过内存分配器（默认是jemalloc，也有部分编译版本使用libc的malloc）来管理内存。jemalloc为了减少频繁分配释放带来的开销，会把内存划分为多种固定大小的内存池，比如8字节、16字节、32字节等。当Redis申请一个15字节的空间时，jemalloc会分配一个16字节的块，多出来的1字节虽然没被使用，但也不会归还给别的请求，这部分浪费属于内碎片。
另一种情况是外碎片。当大量执行SET修改value长度、删除key、过期淘汰等操作后，内存空间中会出现许多不连续的小空洞。比如一个string原来占用100字节，后来改写成50字节，剩下的50字节空间可能因为太小而无法被后续更大的分配复用。这些分散的空洞累积起来，就形成了外部碎片。由于分配器通常不会主动把小空洞合并归还操作系统，RSS就会持续高于实际数据量。
此外，以下几种业务场景特别容易加剧碎片化：value大小差异巨大且频繁变更；使用SPOP、LPOP这类随机删除元素的操作；大量key设置了随机过期时间；主从切换、RDB加载后的内存重分配。判断碎片是否严重，核心看mem_fragmentation_ratio这个指标，一般认为1.0到1.5之间属于正常，超过1.5需要关注，超过2.0就应该及时处理了。
二、主动碎片整理：activedefrag详解
Redis 4.0之前，面对碎片问题几乎只能重启实例或做主从切换。4.0开始引入了active defrag功能，其基本思路是：在服务正常运行的同时，后台线程持续扫描数据，把分散在碎片化内存页上的数据搬运、复制到连续的内存区域，从而让分配器能够释放完整的内存页归还给操作系统。这个过程借鉴了操作系统内存压缩的思想，对业务请求是透明的。
开启该功能非常简单，在redis.conf中配置或通过CONFIG SET动态开启：
redis-cli config set activedefrag yes # 相关控制参数 active-defrag-ignore-bytes 100mb # 碎片字节数低于该值时不整理 active-defrag-threshold-lower 10 # 碎片率低于10%不整理 active-defrag-threshold-upper 100 # 碎片率高于100%时用最大力度整理 active-defrag-cycle-min 1 # 后台整理线程占用CPU的最小比例 active-defrag-cycle-max 25 # 最大CPU比例，避免影响正常请求
几个参数的配合逻辑是：当碎片率超过threshold-lower定义的下限时，整理线程以cycle-min的CPU占比低强度工作；碎片率越高，占用CPU越多，最高达到cycle-max。ignore-bytes则是绝对量的门槛，避免小实例因为几个字节的碎片也频繁整理。需要注意的是，主动整理会带来额外的CPU消耗和一定的延迟抖动，官方建议在CPU资源充足、碎片率确实偏高的情况下使用。如果延迟敏感的业务反馈性能下降，可以适当调低cycle-max。
还有一个细节值得注意：jemalloc的purge行为。可以通过CONFIG SET来控制allocator的内存回收：
# 触发jemalloc归还空闲页（Redis 4.0+） redis-cli memory purge # 查看当前碎片相关指标 redis-cli info memory | grep -E "fragmentation|allocator"
memory purge命令会主动触发分配器的purge操作，把空闲的内存页归还操作系统，对于碎片率不算太高但RSS降不下来的场景，往往执行后立竿见影。有些云厂商的托管Redis也提供了类似的碎片整理按钮，底层就是调用这套机制。
三、被动整理与其他替代方案
如果Redis版本低于4.0，或者不希望开启主动整理带来的CPU开销，还有几种被动方案。最直接的是重启实例：Redis重启后重新从RDB或AOF加载数据，所有键值会连续地重新分配内存，碎片率立刻回到接近1.0。生产上通常结合主从架构来做，先重启从库，执行主从切换，再重启原主库，整个过程业务基本无感知。缺点是需要做数据预热，大实例恢复时间可能较长。
第二种思路是逻辑上的数据搬迁。利用SCAN遍历所有key，将它们逐个DUMP再RESTORE到同一实例（先写入新key再删除旧key），相当于在应用层做了一次碎片整理。也可以借助迁移工具把数据导到新实例再切换流量。这种方式对版本没有要求，但执行周期长，需要控制遍历速率避免影响线上请求。
第三种是源头上减少碎片产生。业务设计上尽量让value大小均匀，避免同一key反复写入大小悬殊的内容；合理设置maxmemory和淘汰策略，防止内存长期处于紧绷状态；如果大量使用哈希或列表，考虑控制单元素大小。对于读多写少的场景，还可以定期做数据重建，比如离线生成新数据集后整体替换。
四、生产环境的碎片治理建议
碎片治理应该纳入日常监控而不是等问题爆发后再处理。建议通过Prometheus配合redis_exporter采集mem_fragmentation_ratio、allocator_frag_ratio（Redis 6.2+提供的分配器视角碎片率）等指标，设置告警阈值。碎片率在1.5以上持续升高时介入处理，避免超过2.0后才动手，因为那时RSS往往已经膨胀到影响部署密度的程度。
参数调优方面给出一个经过验证的保守配置：activedefrag开启，ignore-bytes设为100MB到500MB，threshold-lower设为10，threshold-upper设为100，cycle-min保持1，cycle-max根据机器CPU核数调整，一般不超过20。开启后持续观察instantaneous_ops_per_sec和延迟指标，确认整理线程没有挤占业务请求的处理能力。
最后提醒两点：一是容器化部署时要注意容器内存limit的设置，碎片导致的RSS膨胀可能让容器被OOMKill，建议limit预留一定余量；二是升级到Redis 6.x或7.x能获得更完善的碎片统计和jemalloc新版本的分配算法，部分场景下碎片问题会自然缓解。综合运用主动整理、memory purge和监控告警，绝大多数实例的碎片率都能长期稳定在1.5以内。
Redis内存碎片activedefrag内存优化修改时间：2026-09-05 11:02:37