Redis bgsave 时内存翻倍并非复制业务数据，而是 fork 触发 COW：内核仅复制页表，写入时才拷贝物理页，导致 RSS 暴涨；典型信号是 used_memory_rss / used_memory 比值骤升至 2.5+ 且 latest_fork_usec > 500ms。
redis bgsave 时内存翻倍，真在“复制数据”吗？
不是在复制业务数据，而是在复制页表 + 触发 COW（Copy-On-Write）。Linux fork 子进程做 bgsave 时，内核只复制父进程的页表项（vma），物理内存页仍是共享的；但一旦父进程修改某个页（比如写入新 key、更新过期时间），该页就会被内核实际拷贝一份——这就是 COW 开销的来源。内存监控看到的“翻倍”，往往是 RSS 瞬间飙升，本质是大量脏页被强制分离。
-
bgsave启动瞬间 RSS 不会暴涨，真正涨是在 fork 后持续写入期间 - 如果业务写入压力大（如每秒数万 set / hset）、且 key value 较大（>1KB），COW 压力会指数级上升
-
info memory中的mem_allocator和used_memory_rss与used_memory的比值突然拉大（比如从 1.2 → 2.5+），就是典型信号
怎么确认是 COW 而不是业务数据暴增？
先排除业务侧突增（新定时任务、活动引流、刷量漏洞），再聚焦 fork 行为本身：
- 查看
last_bgsave_time和latest_fork_usec：如果latest_fork_usec异常高（>500ms），说明 fork 耗时长，往往伴随内存页多、COW 压力大 - 对比
used_memory_rss和used_memory：若前者长期 > 后者 ×1.8，且bgsave_in_progress为 1 时 RSS 暴涨，基本锁定 COW - 检查
/proc/<pid>/smaps</pid>中的Pss和Private_Clean：用awk '/^Pss:|Private_Clean:/ {print}' /proc/$(pgrep redis-server)/smaps | head -10快速看页级分布（需有权限）
注意：redis-cli --bigkeys 找不到这类问题——它只扫 key 级别，不反映 fork 时的内存页行为。
调参能缓解，但不能根治：关键配置项实测影响
vm.overcommit_memory 和 sysctl vm.swappiness 是 Linux 层最相关的两个参数，但效果常被高估：
-
vm.overcommit_memory=1（允许过量分配）可降低 fork 失败概率，但不会减少 COW 页数，RSS 该涨还涨 -
vm.swappiness=1可抑制 swap，避免 OOM killer 杀进程，但对 RSS 峰值无改善 - Redis 自身的
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size若设得太激进，会频繁触发bgrewriteaof（同样 fork），和bgsave叠加后更危险
真正有效的是控制写入节奏：比如把批量写入拆成 pipeline 分段提交，或在业务低峰期执行大写操作，给 COW 缓冲窗口。
替代方案：绕开 fork，用 RDB + AOF 混合持久化之外的选择
如果你的场景允许弱一致性（如纯缓存、会话存储），最直接的办法是关掉 RDB：
- 将
save配置全注释（即禁用自动bgsave），仅靠 AOF（appendonly yes）+appendfsync everysec - 或改用
appendfsync no（依赖 OS 刷盘），彻底消除 fork，代价是宕机最多丢 1 秒数据
另一个生产可用路径是 AOF rewrite 改用子进程 + exec 替代 fork（Redis 7.0+ 支持 aof-use-rdb-preamble yes），它用 RDB 格式生成新 AOF 文件，大幅缩短 rewrite 时间，间接降低 fork 频次和驻留时长。
COW 的复杂性在于它藏在内核和 Redis 交界处：你看到的内存数字，是应用逻辑、Redis 数据结构、glibc 内存分配器、Linux 页表管理四层叠加的结果。盯着 used_memory_rss 却不看 latest_fork_usec 和写入模式，就像修车只看转速表不听发动机声音。
