redis 7的activedefrag需同时满足四条件才生效：activedefrag yes、active-defrag-ignore-bytes≥100mb、active-defrag-threshold-lower≥10%、jemalloc协同；仅开开关无效，须结合mem_fragmentation_ratio>1.5且绝对碎片>100mb判断，并确保cpu空闲、allocator为jemalloc且active_defrag_running=1。
Redis 7 的 activedefrag 不是开个开关就能防雪崩，它必须配齐四个参数、逐节点生效、且依赖 jemalloc 和 CPU 余量；否则 mem_fragmentation_ratio 持续 >1.5，会直接引发延迟毛刺、OOM 报错甚至级联雪崩。
怎么确认真是内存碎片在惹祸，而不是 maxmemory 配小了
别改配置前先跑这条命令：redis-cli INFO memory | grep -E "(used_memory|used_memory_rss|mem_fragmentation_ratio)"
- 如果
mem_fragmentation_ratio> 1.5 且used_memory明显低于maxmemory（比如maxmemory=4gb，但used_memory=3.2gb），那就是碎片导致的伪 OOM - 如果
mem_fragmentation_ratio - 如果
mem_allocator不是jemalloc-5.x（多数生产环境默认就是），MEMORY PURGE和activedefrag都无效
为什么只设 activedefrag yes 却完全不工作
activedefrag 是懒触发 + 双阈值驱动，不是常驻线程。它只在主线程空闲、且同时满足两个硬条件时才尝试整理：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
active-defrag-ignore-bytes设太高：比如碎片总量才 60MB，但该值设为100mb→ 直接跳过 -
active-defrag-threshold-lower填错单位：它实际是「百分比 ×10」，填12表示 ≥12% 才触发；默认10（即 10%）太保守，很多从节点根本达不到 - CPU 持续满载：从节点承担读+复制压力，
activedefrag抢不到时间片，active_defrag_running长期为 0
Redis 7 从节点必须显式配的四个参数（缺一不可）
集群或哨兵模式下，CONFIG SET 不跨节点、不持久化。每个从节点都得单独改 redis.conf 并重启（或 CONFIG REWRITE + CONFIG SET 双保险）：
-
activedefrag yes：总开关，注意必须是yes，不是on或1 -
active-defrag-ignore-bytes 100mb：避免小碎片反复触发整理，白耗 CPU -
active-defrag-threshold-lower 12：比默认更敏感（12 表示 ≥12%），从节点更容易启动整理 -
active-defrag-cycle-min 100和active-defrag-cycle-max 500：提高单次整理时长上限，弥补从节点 CPU 空闲时间少的问题
怎么验证从节点真在整理，而不是“看起来开了”
别只信 CONFIG GET activedefrag 返回 yes。要看运行时状态：
- 执行
redis-cli -h slave-ip -p port INFO memory | grep -E "(mem_fragmentation_ratio|active_defrag)" - 确认
active_defrag_running偶尔为1（不是一直为 1，而是间歇性出现） - 观察
active_defrag_hits是否随时间缓慢增长；若 10 分钟内无变化，说明仍未触发 - 对比
used_memory_rss和used_memory差值：若差值从 3GB 缓慢降到 2.2GB，说明整理生效
最容易被忽略的是：从节点即使配全参数，若 mem_allocator 不是 jemalloc，或 jemalloc 版本太老（如 4.x），activedefrag 依然不会真正归还内存。
