判断内存碎片是否真高需结合mem_fragmentation_ratio、used_memory和used_memory_rss：ratio>1.5且rss与used_memory差值超100MB才需干预；ratio
怎么判断内存碎片率是否真高了
别光看 INFO memory 输出里那个 mem_fragmentation_ratio 数字，得结合 used_memory 和 used_memory_rss 一起看。比如 mem_fragmentation_ratio 是 1.86，但 used_memory 才 1GB，那碎片绝对值才 860MB，影响有限；可如果 used_memory 是 10GB，碎片就接近 9GB，这就必须动了。
mem_fragmentation_ratio ：说明 Redis 内存不够用了，OS 开始 swap，比碎片更危险1.0 ：正常波动范围，不用干预-
ratio > 1.5且used_memory_rss - used_memory > 100MB：该清理了
启用 activedefrag 前必须确认的三件事
Redis 4.0+ 才支持在线碎片整理，但开了不等于就起效——它是一组条件触发的“懒整理”，漏掉任意一个配置，activedefrag 就是摆设。
- 确认 Redis 版本：
redis-cli INFO server | grep redis_version，低于 4.0 直接放弃 - 确认内存分配器是
jemalloc（默认）：redis-cli INFO memory | grep mem_allocator，如果是libc，activedefrag不生效 - 确认没被运维脚本或配置中心覆盖：检查
redis.conf里是否真写了activedefrag yes，而不是只在某次临时CONFIG SET过
四个关键配置项怎么设才不翻车
官方文档说“同时满足两个条件才触发”，但实际是四个参数协同控制节奏和底线。设得太激进，CPU 被吃满，请求延迟飙升；设得太保守，碎片永远清不完。
-
activedefrag yes：总开关，必须开 -
active-defrag-ignore-bytes 100mb：碎片总量不到 100MB，不启动整理（避免小碎片白忙活） -
active-defrag-threshold-lower 10：碎片占used_memory_rss比例 ≥10% 才开始（注意不是占used_memory） -
active-defrag-cycle-min 25和active-defrag-cycle-max 75：整理时 CPU 占用控制在 25%~75% 之间，超了就暂停——这是防卡顿的核心保护
示例配置段（加到 redis.conf）：
activedefrag yes active-defrag-ignore-bytes 100mb active-defrag-threshold-lower 10 active-defrag-threshold-upper 100 active-defrag-cycle-min 25 active-defrag-cycle-max 75
为什么有时候开了也没反应
最常被忽略的一点：activedefrag 只在 Redis 空闲时工作。如果你的实例 QPS 长期压在 2w+，CPU 持续 95%，那它根本没机会抢到 CPU 时间片去整理碎片。
- 查当前是否在整理：
redis-cli INFO memory | grep active_defrag_running，返回 1 才真在跑 - 查整理进度：
redis-cli INFO memory | grep defrag，关注active_defrag_hits是否缓慢增长 - 如果长期为 0，优先降负载或调大
active-defrag-cycle-min（但别超过 50），而不是怀疑配置错了
碎片整理不是魔法，它本质是把数据从一堆零散页拷到新连续页，再释放旧页——这个过程必然争抢内存带宽和 CPU，高负载下宁可不动。
