redis bgsave fork 时内存暴增主因是cow机制下高频小key更新、大value部分覆盖及del+set替换大对象触发大量页复制；可通过jemalloc优化、禁用淘汰策略、监控/proc/pid/statm第六列writecopy值、压缩rdb及启用主动碎片整理来预估和控制。
Redis RDB fork 时内存暴增，怎么预估和控制
Redis 执行 bgsave 时会 fork 子进程，此时内核启用 Copy-On-Write（COW）机制——父进程继续写入，被修改的内存页才真正复制。但只要父进程有写操作，就可能触发大量页复制，导致 RSS 内存瞬间翻倍。
关键不是“能不能避免 COW”，而是“哪些写行为最伤内存”。实测发现：高频小 key 更新（如计数器）、大 value 的部分覆盖（如 HSET 大哈希中的单个字段）、以及 DEL + SET 替换大对象，最容易引发密集页分裂。
- 用
INFO memory中的mem_allocator确认是否为 jemalloc（推荐），它比 libc malloc 更友好地处理 COW 后的页释放 - 监控
INFO stats中的evicted_keys和expired_keys：如果bgsave期间突增，说明内存压力已逼近 limit，fork 更危险 - 设置
maxmemory-policy为noeviction可避免 save 过程中因淘汰逻辑加剧内存抖动（但需确保业务能承受 OOM 风险）
如何实时观察 COW 过程中的内存增量
Linux 提供了 /proc/<pid>/status</pid> 中的 CopyOnWrite 字段（实际是 MMUPageSize 和 RssAnon 的组合推断），但更直接的是看 WriteCopy —— 它在 /proc/<pid>/statm</pid> 第六列（单位：页），代表当前被 COW 的物理页数。
注意：这个值只在 fork 后子进程存活期间有意义；子进程退出（RDB 写完）后归零。别用 top 或 ps 看 RSS，它们显示的是父子进程 RSS 总和，无法分离 COW 开销。
- 执行
bgsave后，立即查主进程 PID：redis-cli INFO server | grep process_id - 持续采样：
awk '{print $6}' /proc/<pid>/statm</pid>，乘以getconf PAGESIZE（通常 4096）得字节数 - 若该值在几秒内从 0 跳到 >500MB，说明正在大量复制脏页——此时应暂停写入或推迟备份
优化 RDB 文件大小本身就能减轻 COW 压力
RDB 文件越小，fork 后子进程需要写的磁盘数据越少，生命周期越短，COW 窗口就越窄。但压缩不是万能的：启用 rdbcompression yes（默认）会增加 CPU 开销，而 rdbchecksum yes 对内存无影响，仅多一次校验计算。
真正有效的是减少 RDB 中“冗余数据”：比如过期但未清理的 key、被 DEL 掉却还留在内存里的大对象（因 lazyfree 未完成）、以及未配置 active-defrag 导致的内存碎片。
- 定期运行
MEMORY USAGE <key></key>检查是否存在“逻辑删除但物理未释放”的大 key - 开启
activedefrag yes并调低active-defrag-threshold-lower（如设为 10），让 Redis 在空闲时主动整理内存页，降低 COW 时需复制的页数 - 禁用
rdbcompression仅当 CPU 是瓶颈且网络/磁盘带宽充足；否则压缩后 RDB 写入更快，子进程退出更早，反而更省内存
为什么 save 不触发 COW 却更危险
save 是同步阻塞命令，不 fork，自然没 COW。但它会让 Redis 主线程停写几百毫秒甚至数秒——这在高吞吐场景下等于服务雪崩。很多人误以为“不用 fork 就安全”，其实只是把内存风险转嫁成了可用性风险。
更隐蔽的问题是：save 期间所有写命令堆积在 client output buffer，一旦 buffer 溢出（受 client-output-buffer-limit 控制），连接会被强制关闭，造成批量超时。
- 永远不要在生产环境手动执行
save - 如果必须用同步快照（如某些灾备工具要求），改用
redis-cli --rdb /tmp/dump.rdb，它走的是 DEBUG OBJECT + 协议解析路径，不经过主线程 save 流程 - 监控
INFO clients中的client_longest_output_list，若 >1000，说明输出缓冲区已在积压，此时bgsave的 COW 压力会进一步放大
COW 内存增量不是固定值，它取决于 fork 时刻的内存脏页分布、后续写入模式、以及内核版本对页表管理的优化程度。上线前务必在压测环境模拟真实写负载跑一次 bgsave，用 /proc/pid/statm 实测峰值，而不是依赖理论估算。
