Redis持久化会推高mem_fragmentation_ratio，因fork()触发COW导致used_memory_rss飙升而used_memory不变；主线程写入引发页复制与jemalloc碎片积累，叠加持久化期间activedefrag暂停，使碎片率常升至1.8～2.5。
Redis持久化操作会临时推高 mem_fragmentation_ratio
执行 bgsave 或 bgrewriteaof 时，Redis 主进程会调用 fork() 创建子进程。这个动作本身不直接产生碎片，但会触发操作系统对内存页表的复制（Copy-On-Write），导致 used_memory_rss 短暂飙升——而 used_memory 不变，因此 mem_fragmentation_ratio 在监控上会明显跳升，常达 1.8～2.5 甚至更高。
fork() 后的写入行为才是碎片增长主因
子进程存在期间，主线程若修改任何已有数据（如 SET 一个已存在的 key），就会触发 COW：原内存页被复制一份供子进程读取，主线程在新页上写入。此时旧页若未被完全释放或无法合并，就容易形成外部碎片。尤其当 key value 频繁变长（如追加日志类字符串）、或大量小对象被反复更新时，jemalloc 分配器难以回收中间空隙，mem_fragmentation_ratio 在持久化结束后仍维持高位。
- 典型场景：RDB 快照期间持续
APPEND大量日志，快照结束后的info memory显示mem_fragmentation_ratio从 1.3 升至 1.9 - 影响程度取决于：Redis 实例内存大小、活跃 key 的更新密度、value 平均长度变化幅度
- 注意：
save命令（非后台）虽不 fork，但会阻塞主线程并独占内存分配，同样可能加剧分配器内部碎片积累
自动碎片整理（activedefrag）在持久化期间默认暂停
Redis 的主动碎片整理机制会在检测到负载升高（如 CPU 使用率 > active-defrag-cycle-max 阈值）时自动降频或暂停。而 bgsave / bgrewriteaof 过程中，主线程和子进程都会消耗 CPU，系统通常判定为高负载，导致 activedefrag 实际处于 idle 状态，无法及时回收刚产生的碎片。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 验证方式：执行
redis-cli config get activedefrag确认值为yes，再观察INFO memory中mem_allocator是否为jemalloc（仅 jemalloc 支持运行时整理） - 关键参数：
active-defrag-cycle-max默认 25，建议生产环境设为 ≤ 30，避免与持久化争抢 CPU；active-defrag-ignore-bytes至少设为100mb，防止碎片太小时频繁触发 - 手动干预：可在持久化窗口期结束后，立即执行
MEMORY PURGE强制归还未使用的内存页给操作系统（仅对 jemalloc 有效）
真正危险的是“持久化 + 内存淘汰”叠加场景
当 maxmemory 已设且接近上限，同时开启 AOF 重写或 RDB 快照，就极易触发连锁反应：子进程占用 RSS → 触发淘汰策略（如 volatile-lru）→ 大量 key 删除 → jemalloc 无法立即合并空闲块 → mem_fragmentation_ratio 持续 > 2.0，且 used_memory_rss 居高不下。
- 现象：top 显示 redis 进程 RES 持续 8GB，但
used_memory仅 4.2GB，evicted_keys每秒递增 - 这不是配置错误，而是内存分配器在高压下进入低效状态的表现
- 最稳妥的缓解方式不是关持久化，而是错峰：把
save规则（如save 60 10000）中的时间窗口拉长，或改用replica-serve-stale-data no配合从库定时 dump，减轻主库压力
碎片率不是静态指标，它在持久化这类重量级操作中会动态劣化。盯住 mem_fragmentation_ratio 的波动节奏，比只看单次数值更有意义；而真正的修复点，往往藏在 fork() 之后那几秒的写入模式里。
