确认内存碎片导致伪oom：需同时满足mem_fragmentation_ratio>1.5且used_memory明显低于maxmemory；仅开activedefrag yes无效，必须配齐active-defrag-ignore-bytes、active-defrag-threshold-lower、active-defrag-cycle-min/max四参数并逐节点生效。
Redis集群因内存碎片触发OOM，不是数据真满了，而是jemalloc凑不出连续内存块——必须开activedefrag，但只设activedefrag yes远远不够，漏掉任一阈值条件，它就完全不工作。
怎么确认真是内存碎片惹的祸，而不是maxmemory配小了
别急着改配置，先用redis-cli INFO memory看三行关键输出：
-
used_memory：Redis自己统计的“干净”内存用量（比如 3.2GB） -
used_memory_rss：操作系统实际分配的物理内存（比如 5.8GB） -
mem_fragmentation_ratio：两者比值（5.8 / 3.2 ≈ 1.81）
只有同时满足这两个条件，才是碎片导致的伪 OOM：
-
mem_fragmentation_ratio > 1.5且 -
used_memory明显低于maxmemory（比如maxmemory=4gb，但used_memory=3.2gb）
如果 mem_fragmentation_ratio ，说明 OS 已开始 swap，比碎片更紧急，得立刻扩容或降负载。
为什么开了activedefrag yes却没反应
最常被忽略的事实：activedefrag 是“懒触发 + 条件驱动”的后台动作，不是常驻线程。它只在以下时机尝试执行：
- 每次内存分配/释放后，由 jemalloc 回调通知 Redis
- 且此时 Redis 主线程 CPU 空闲度足够（QPS 不能长期压在 2w+、CPU 持续 95%）
- 且同时满足两个硬性阈值（缺一不可）：
active-defrag-ignore-bytes和active-defrag-threshold-lower
所以常见“没反应”的真实原因：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 碎片总量才 60MB，但
active-defrag-ignore-bytes设的是100mb→ 不触发 -
used_memory_rss是 5GB，碎片 700MB，占比仅 14%，但active-defrag-threshold-lower设的是15→ 不触发 - 集群节点 CPU 长期跑满，
activedefrag根本抢不到时间片
activedefrag 四个核心参数怎么设才不卡主服务
这四个参数是协同生效的，不是只开开关就行。重点是控制节奏和底线：
-
activedefrag yes：总开关，必须为yes（注意不是on） -
active-defrag-ignore-bytes 100mb：碎片绝对值不到 100MB，直接跳过（防小碎屑白忙） -
active-defrag-threshold-lower 10：碎片占used_memory_rss≥10% 才启动（注意分母是rss，不是used_memory） -
active-defrag-cycle-min 25和active-defrag-cycle-max 75：整理时 CPU 占用压在 25%~75% 区间，超了就暂停——这是防延迟飙升的关键保护
示例安全配置（加到 redis.conf 或用 CONFIG SET 动态生效）：
activedefrag yes active-defrag-ignore-bytes 100mb active-defrag-threshold-lower 10 active-defrag-cycle-min 25 active-defrag-cycle-max 75
⚠️ 注意：active-defrag-threshold-upper 默认 100，一般不用动；改完不会立刻干活，要等下次满足条件的内存事件触发。
集群环境下特别要注意的三个前提
在 Redis Cluster 中启用 activedefrag，光配对参数还不够，必须逐节点确认：
-
redis-cli INFO server | grep redis_version：每个 shard 节点都得 ≥ 4.0，旧版无效 -
redis-cli INFO memory | grep mem_allocator：必须是jemalloc，如果是libc，activedefrag直接失效 - 检查是否被运维平台覆盖：有些集群用配置中心下发
redis.conf，你本地改了可能被回滚，得确认最终生效的是哪份配置
真正卡住的点，往往不在“有没有开”，而在“阈值设太保守”或者“根本没意识到 used_memory_rss 和 used_memory 不是一回事”。碎片清理不释放内存，只是把散落的空洞拼成大块——所以即使 mem_fragmentation_ratio 降到 1.1，只要 used_memory 接近 maxmemory，淘汰照样触发。
