mem_fragmentation_ratio > 1.5 不一定需处理，必须同时满足该比值>1.5且used_memory_rss−used_memory>100mb才需干预；仅比值高而绝对碎片量小则影响有限。
mem_fragmentation_ratio > 1.5 不一定真要处理
只看 mem_fragmentation_ratio 容易误判。它只是比值：used_memory_rss / used_memory，真正影响性能的是绝对碎片量。必须同时满足两个条件才值得干预：
mem_fragmentation_ratio > 1.5used_memory_rss - used_memory > 100mb
比如 mem_fragmentation_ratio 是 1.8，但 used_memory 只有 600MB，那碎片才 480MB，对多数实例影响有限；可如果 used_memory 是 15GB，碎片就近 12GB，OS 都可能开始 swap——这时候延迟会明显升高，mem_fragmentation_ratio 就是更紧急的信号。
CONFIG SET activedefrag yes 后 active_defrag_running 一直是 0？
开了开关不等于启动了整理，activedefrag 是“闲时抽查式”工作，依赖四个参数协同判断是否干活。常见失败点：
- Redis 版本 redis-cli INFO server | grep redis_version 确认 ≥ 4.0
- 内存分配器不是
jemalloc：检查redis-cli INFO memory | grep mem_allocator，返回libc则activedefrag完全无效 - 配置被覆盖：
CONFIG SET是临时生效，重启即丢；确认redis.conf里真实存在activedefrag yes且没被运维脚本重写 - 实例太忙：QPS 长期 > 1.5w 或 CPU 持续 > 90%，
active_defrag_running基本卡死在 0
Redis 6.2+ 怎么立刻释放物理内存？用 MEMORY PURGE
MEMORY PURGE 是唯一能“推一把”的命令，它强制让 jemalloc 或 tcmalloc 把可还的内存归还给 OS。执行后观察 used_memory_rss 是否下降——这才是真实释放的物理内存。
注意：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 只对
jemalloc/tcmalloc有效，libc下执行无反应 - 不是“清理碎片”，而是“释放已空闲但未归还的页”，对刚删完大 key 的场景最见效
- 无需等待空闲周期，但会短暂增加主线程负载，别在高峰执行
示例：redis-cli MEMORY PURGE
为什么 UNLINK 不能解决历史碎片？
UNLINK 替代 DEL 能把删除逻辑异步化，减少阻塞，但它只影响“刚删的键”的内存回收节奏，对已存在的外部碎片（比如之前频繁改写留下的不连续空闲块）完全无效。
典型误区：
- 以为换
UNLINK就能降mem_fragmentation_ratio→ 实际只改善延迟，不减少 RSS - 对小 key 频繁
UNLINK→ 内部碎片仍堆积，jemalloc的固定档位分配策略照旧生效 - 忽略分配器本身行为 → 即便所有操作都
UNLINK，只要没触发MEMORY PURGE或activedefrag，碎片就还在 RSS 里占着
顽固碎片最终得靠 MEMORY PURGE（6.2+）、调参后的 activedefrag，或换用更激进归还的 tcmalloc。碎片率压到 1.3 左右就是合理结果，强求 1.0 往往反伤性能。
