redis内存碎片率通过mem_fragmentation_ratio（used_memory_rss/used_memory）判断，>1.5通常碎片严重，但需结合mem_allocator、used_memory_peak等综合分析，jemalloc下持续>1.3才需干预。
Redis内存碎片率怎么看
内存碎片率（mem_fragmentation_ratio）是判断是否需要开启自动整理的关键指标，它等于used_memory_rss / used_memory。值大于1.5通常说明碎片较严重，但不能只看这一个数——比如在启用了透明大页（THP）的Linux系统上，used_memory_rss会被虚高，导致误判。
查当前碎片率最直接的方式是执行：
redis-cli info memory | grep mem_fragmentation_ratio
- 生产环境建议配合
INFO memory里的used_memory_peak和mem_allocator一起看：如果用的是jemalloc且mem_fragmentation_ratio持续＞1.3，才值得进一步干预 - 注意避开高峰期查，因为
used_memory_rss会受瞬时分配/释放抖动影响 - 如果用的是
libc分配器，activedefrag基本无效，得先切到jemalloc
activedefrag相关参数怎么配才不翻车
Redis 4.0+才支持activedefrag，但它不是开个开关就完事。默认关闭，开启后行为由一组阈值参数控制，配错反而拖慢主线程。
-
active-defrag-threshold-lower 10：内存碎片率超过10%才启动整理（注意是百分比数值，不是小数） -
active-defrag-threshold-upper 100：碎片率超100%（即2.0）时激进整理 -
active-defrag-ignore-bytes 100mb：小于100MB的碎片块直接跳过，避免为小碎片反复扫描 -
active-defrag-cycle-min 25：空闲时最低用25% CPU时间做整理；active-defrag-cycle-max 75限制峰值占用
线上建议从保守起步：active-defrag-threshold-lower 15、active-defrag-cycle-min 10、active-defrag-cycle-max 25，观察监控中evicted_keys和expired_keys有无异常突增。
为什么开了activedefrag还是频繁触发淘汰
自动整理解决的是物理内存碎片，不是逻辑内存不足。即使碎片率降到1.1，只要used_memory逼近maxmemory，淘汰机制照常触发。
- 常见误区：以为
activedefrag能“腾出更多可用内存”，其实它只是把分散的小块合并成大块，不释放已分配的内存 - 如果
maxmemory-policy设的是allkeys-lru或volatile-lru，淘汰优先级远高于整理动作，整理根本来不及生效 - 某些场景下（如大量短生命周期key + 高频写入），整理速度跟不上碎片产生速度，此时应优先优化key生命周期或引入分片
jemalloc版本和编译选项影响有多大
Redis默认静态链接jemalloc，但不同版本对碎片整理的支持差异明显。5.0.0之前的老版本jemalloc（如3.x）不支持mallctl的purge接口，activedefrag实际效果很弱。
- 确认方式：
redis-cli info memory | grep mem_allocator
输出含jemalloc-5.2.1才算靠谱 - 源码编译时务必加
--with-jemalloc，别依赖系统包管理器装的旧版 - 若用Docker，检查基础镜像——
redis:7-alpine用的是musl libc，不支持activedefrag，必须换redis:7（Debian系）
碎片问题本质是内存分配器与数据访问模式的匹配问题，activedefrag只是缓兵之计。真正稳定的解法，往往藏在key设计、过期策略和实例粒度里。
