一眼看出oom是内存碎片导致：当used_memory远低于maxmemory但报oom时，查info memory中used_memory_rss / used_memory = mem_fragmentation_ratio > 1.5（>2.0基本卡死），且used_memory_rss - used_memory差值过大（如>500mb），即为碎片假满。
怎么一眼看出OOM是内存碎片惹的祸
Redis 报 OOM command not allowed when used memory > 'maxmemory'，但 used_memory 明明远低于 maxmemory？这不是真满，是“假满”——used_memory_rss 过高、mem_fragmentation_ratio 膨胀导致 jemalloc 拿不出连续内存块。直接查 INFO memory，盯死这三行：
-
used_memory：Redis 自己统计的干净内存用量（数据+缓冲区） -
used_memory_rss：操作系统实际塞给 Redis 进程的物理内存（含碎片、共享库、堆栈） -
mem_fragmentation_ratio=used_memory_rss / used_memory，>1.5 就得动手，>2.0 基本卡死
比如 used_memory=1.2GB，maxmemory=2GB，看着还有 800MB 余量，但 used_memory_rss=3.1GB → mem_fragmentation_ratio≈2.6，这就是典型碎片 OOM。
为什么只看 used_memory 会误判
used_memory 是 Redis 内存分配器（如 jemalloc）上报的“逻辑用量”，它不反映底层物理内存是否连续。jemalloc 为了减少系统调用，会预申请大块内存并自行管理；长期增删 key 后，空闲内存被切成小碎片，哪怕总空闲字节数够，也凑不出当前命令需要的一整块（比如 1MB 的新 String 或 Hash slot）。这时候 used_memory 没涨，used_memory_rss 却居高不下，mem_fragmentation_ratio 就成了唯一可信的“碎片体温计”。
- 值
- 值 1.0–1.5：正常，jemalloc 碎片在可控范围
- 值 >1.5：碎片开始影响写入稳定性，尤其在大 value、频繁 hset/hdel 场景下更敏感
如何用 redis-cli 快速抓取碎片差值
别等 OOM 再排查，日常巡检就该算清楚 used_memory_rss - used_memory 这个差值。它代表“被碎片吃掉的物理内存”，单位字节，数值越大越危险：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli INFO memory | grep -E "(used_memory|used_memory_rss|mem_fragmentation_ratio)"
或者用一行脚本提取差值（单位 MB）：
redis-cli INFO memory | awk -F': ' '/used_memory_rss/ {rss=$2} /used_memory/ {used=$2} END {printf "Fragmented: %.1f MB\n", (rss-used)/1024/1024}'
- 差值 >200MB 且持续上升 → 检查是否有大量小 key 频繁过期或删除
- 差值 >500MB → 建议立即开启主动碎片整理（见下一条）
- 注意：云环境（如阿里云 ECS、AWS EC2）中，
used_memory_rss还可能包含内核 page cache，需结合allocator_frag_ratio辅助判断是否纯 jemalloc 碎片
Redis 4.0+ 怎么安全开启自动碎片整理
别手动重启或 flushdb——那等于把问题推给下游服务。Redis 4.0 引入了运行时碎片整理能力，通过 jemalloc 的 purge 和 decay 行为实现，无需停服：
- 临时启用：
CONFIG SET activedefrag yes（立刻生效，但重启后失效） - 永久生效：在
redis.conf中加两行：activedefrag yesactive-defrag-ignore-bytes 100mb（只对碎片超 100MB 的内存块整理） - 关键参数：
active-defrag-threshold-lower 10（碎片率 >10% 才触发）、active-defrag-cycle-min 25（最低 CPU 占用 25%，避免抢资源）
开启后观察 INFO memory 中的 active_defrag_running（1=正在整理）和 mem_fragmentation_ratio 是否缓慢下降。注意：整理过程会轻微增加 CPU 和延迟，避开业务高峰时段操作。
碎片不是玄学，是 jemalloc 在真实 workload 下的必然副产品。真正容易被忽略的是：监控不能只看 used_memory 是否超限，必须把 used_memory_rss 和差值纳入告警阈值——哪怕 used_memory 只用了 60%，只要 mem_fragmentation_ratio > 1.8 或差值突破 300MB，就得介入。
