DEL或自动过期后used_memory下降但used_memory_rss不降，是因为jemalloc保留空闲页供复用，导致内存碎片率mem_fragmentation_ratio>1.5时RSS滞留；需通过避免大小混存、分片删除、定期PURGE或Redis 7.0+启用activedefrag缓解。
为什么 DEL 或自动过期后 used_memory 不下降？
不是 Redis 没删，而是 jemalloc 没把内存还给操作系统。Redis 删除 key 后只通知分配器“这块数据不用了”，但 jemalloc 会把空闲页保留在进程内，供后续新 key 复用——这叫内存页驻留（page retention）。所以 used_memory（Redis 自己统计的数据内存）会立刻下降，但 used_memory_rss（操作系统看到的物理内存占用）往往纹丝不动。
mem_fragmentation_ratio 超过 1.5 就该警惕
这个比值 = used_memory_rss / used_memory，反映的是内存碎片程度。正常范围是 1.0–1.5；超过 1.5，说明 jemalloc 管理的空闲页太零碎，没法合并成大块还给系统，大量内存被“卡”在碎片里。
- 常见诱因：频繁写入/删除不同大小的 key（比如一会儿存 12B 的 token，一会儿存 1.2KB 的用户 profile）
- jemalloc 默认按固定 size class 分配（如 8B、16B、48B…2KB），小对象删完容易留下无法复用的“边角料”
-
INFO memory里看到mem_fragmentation_ratio:1.72，基本可断定是碎片主导的内存滞留
别依赖 MEMORY PURGE，它只对 jemalloc 有效且有前提
MEMORY PURGE 命令本质是调用 jemalloc 的 mallctl("arena.<n>.purge")</n>，强制释放 arena 中已标记为 free 的页。但它有几个硬限制：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 仅在使用 jemalloc 时生效（
mem_allocator:jemalloc-5.1.0），libc/tcmalloc 不支持 - 必须确保对应 arena 当前没有活跃分配（否则 purge 会被跳过）
- 集群环境下需逐个节点执行，不能批量触发
- 生产环境慎用：可能引发短暂延迟，尤其在高负载时
执行前先确认：INFO memory 输出中 mem_allocator 确实是 jemalloc，且 mem_fragmentation_ratio > 1.5。
真正有效的长期缓解手段
碎片问题没法靠一次 purge 彻底解决，关键在预防和节奏控制：
- 避免混用极小和极大 value：比如不要让同一个 hash 同时存 3 字符的 status 和 500KB 的 log blob
- 批量删除改用
SCAN+DEL分片执行，防止单次操作阻塞并加剧 arena 不平衡 - 定期（如低峰期）执行
MEMORY MALLOC-STATS查看各 arena 分配情况，发现倾斜及时MEMORY PURGE - 如果业务允许，升级到 Redis 7.0+ 并启用
activedefrag yes，它会在后台渐进式整理碎片（但不保证立即释放 RSS）
最常被忽略的一点：used_memory_rss 不降 ≠ 内存泄漏，也不代表 Redis 会持续吃满物理内存——只要 mem_fragmentation_ratio 稳定在 1.3 左右，就属于 jemalloc 的健康驻留行为。
