需结合mem_fragmentation_ratio>1.5且used_memory_rss−used_memory>100mb判断真高碎片，单看比值易误判；ratio高但used_memory小则绝对碎片量小，影响有限；反之used_memory大时碎片绝对值巨大才需干预。
怎么确认当前碎片率真高了，而不是误报
别只盯着 mem_fragmentation_ratio 一个数字。它只是比值，得结合 used_memory 和 used_memory_rss 看绝对量：mem_fragmentation_ratio > 1.5 且 used_memory_rss - used_memory > 100mb 才算真正需要干预。比如 ratio 是 1.9，但 used_memory 只有 800MB，那碎片才 720MB，影响有限；可如果 used_memory 是 12GB，碎片就近 11GB，就得动手了。mem_fragmentation_ratio 更危险——说明 OS 已开始 swap，响应会卡顿，优先级高于碎片整理。
activedefrag 不是“一开就清”，必须满足四个条件才真干活
开了 activedefrag yes 只是打开门，不等于有人进门干活。它实际依赖四个参数协同判断是否启动、何时停手：
-
active-defrag-ignore-bytes 100mb：碎片总量不到 100MB，直接跳过（避免为几 MB 白耗 CPU） -
active-defrag-threshold-lower 10：碎片占used_memory_rss的比例 ≥10% 才触发（注意不是占used_memory） -
active-defrag-cycle-min 25和active-defrag-cycle-max 75：整理时 CPU 占用控制在 25%~75%，超了就暂停——这是防延迟飙升的关键保护
漏掉任意一个，active_defrag_hits 就长期为 0，active_defrag_running 几乎不翻 1。
为什么 CONFIG SET 后没反应？常见执行失败点
最常踩的坑是：以为 CONFIG SET activedefrag yes 就完事了，结果 INFO memory 里 active_defrag_running 始终为 0。原因包括：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Redis 版本低于 4.0：
redis-cli INFO server | grep redis_version必须 ≥ 4.0 - 内存分配器不是
jemalloc：redis-cli INFO memory | grep mem_allocator必须返回jemalloc；若为libc，activedefrag完全无效 - 配置被覆盖：运维脚本或配置中心可能在启动后又把
activedefrag改回no，要检查redis.conf文件里是否真实存在该行 - 实例太忙：QPS 长期 >1.5w，CPU 持续 >90%，
activedefrag根本抢不到时间片——它只在 Redis 空闲时工作
Redis 6.2+ 怎么手动强制清理一次
如果你需要立刻见效（比如刚删完一批大 key，想马上释放物理内存），MEMORY PURGE 是唯一能“推一把”的命令，但它只对 jemalloc 或 tcmalloc 有效：
redis-cli MEMORY PURGE
执行后观察 used_memory_rss 是否下降——这才是真实释放的物理内存。注意：mem_fragmentation_ratio 下降但 used_memory_rss 不变，说明只是内部重排，没还给 OS，大概率是分配器或系统限制（如禁用了 madvise(MADV_DONTNEED)）导致的。
老版本（MEMORY PURGE，只能靠等 activedefrag 自动扫描，或重启实例——后者虽有效，但生产环境慎用。
