判断是否需干预内存碎片，必须同时满足mem_fragmentation_ratio>1.5且used_memory_rss−used_memory>100mb；仅比值高不意味真需处理，还要看绝对碎片量、分配器类型、实例负载及activedefrag四参数协同配置。
Redis内存碎片率过高，不能只看mem_fragmentation_ratio就开activedefrag——它可能根本不动，甚至开了也白开。
怎么判断是不是真该干预了
别被mem_fragmentation_ratio单独骗了。这个值只是比值，得结合used_memory和used_memory_rss一起算：
mem_fragmentation_ratio ：OS已经开始swap，比碎片更紧急，优先查内存不足或maxmemory设太小1.0 ：正常波动，不用动-
mem_fragmentation_ratio > 1.5且used_memory_rss - used_memory > 100mb：这才是真要出手的信号
举个例子：mem_fragmentation_ratio是1.86，但used_memory才800mb，那碎片绝对值不到700mb，影响有限；可如果used_memory是12gb，碎片就近11gb，就得立刻调参。
为什么activedefrag yes之后没反应
最常见原因：Redis压根没空干活。它只在主线程空闲时抽时间整理，不是后台常驻线程。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- QPS长期超1.5w、CPU持续>90%，
active_defrag_running基本一直为0 -
redis-cli INFO memory | grep active_defrag里active_defrag_hits长期不涨，说明触发条件没满足 - 检查
active-defrag-ignore-bytes和active-defrag-threshold-lower是否仍用默认值（100mb + 10%），太保守会导致“永远等不到启动” - 确认
mem_allocator是jemalloc，不是libc——后者开了activedefrag也还不了物理内存
四个关键参数怎么设才不翻车
光开activedefrag yes远远不够。这四个参数必须协同调整，否则要么不干活，要么吃满CPU：
-
active-defrag-ignore-bytes 100mb：碎片总量不到100MB不启动，避免为小碎片反复调度 -
active-defrag-threshold-lower 12：碎片率≥12%（即mem_fragmentation_ratio ≥ 1.12）才开始，比默认10更敏感 -
active-defrag-cycle-min 100：单次整理至少抢100ms CPU时间，避免“蜻蜓点水” -
active-defrag-cycle-max 500：上限设到500ms，防止卡顿；实际占用由Redis动态调节
注意：active-defrag-threshold-lower单位是百分比×10（写12=12%，不是0.12），文档容易看错。
集群环境必须逐节点配，不能靠CONFIG SET糊弄
Redis Cluster节点之间不共享配置，CONFIG SET只对当前连接节点生效，重启就丢。
- 每个master/slave节点都要单独执行：
redis-cli -h 10.0.1.5 -p 6380 CONFIG SET activedefrag yes - 更要编辑每个节点的
redis.conf，把全部active-defrag-*参数显式写进去，再重启 - 验证是否生效：
redis-cli INFO memory | grep -E "(mem_fragmentation_ratio|active_defrag)"，重点看active_defrag_running是否偶发为1
真正难的不是配置，而是识别“整理无效”的场景：比如大量小对象分散、过期key堆积未清理、value大小差异极大——这些情况下activedefrag能做的很有限，used_memory_rss降不下来，就得考虑滚动重启或重构数据结构。
