redis rdb快照期间oom的根本原因是linux fork的写时复制（cow）机制，父进程修改已分配内存页时需为子进程拷贝副本；估算cow内存需结合dirty_ratio、vm.overcommit_memory及脏页增速，容器中须按cgroup limit而非宿主机内存计算并预留30% buffer。
Redis RDB快照期间写入导致OOM的根本原因
根本不是Redis本身内存暴涨，而是Linux fork子进程做RDB时触发的写时复制（COW）机制——父进程继续写入，只要修改了被fork时已分配的内存页，内核就得为子进程单独拷贝一份。如果快照期间写入量大、内存碎片多、或启用了大量大key，COW开销可能瞬间吃光剩余内存。
如何估算COW所需预留内存
不能简单按“一半内存”拍脑袋。关键看三个动态因素：dirty_ratio、vm.overcommit_memory设置、以及实际脏页增长速率。实操建议如下：
- 用
INFO memory查mem_allocator和used_memory_rss，确认是否使用jemalloc（比glibc malloc更抗碎片） - 监控
latest_fork_usec—— 如果 > 1s，说明fork耗时长，COW窗口期拉长，风险陡增 - 用
cat /proc/$(pidof redis-server)/status | grep VmRSS对比fork前后RSS变化，粗估单次fork实际COW压力 - 若启用了
activedefrag yes，务必关闭——它在fork前后主动整理内存，反而加剧页分裂，放大COW
真正有效的缓解手段（非调参）
调 vm.overcommit_memory=1 或增大 overcommit_ratio 是饮鸩止渴，掩盖问题而非解决。生产环境应优先落地这些：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 改用
redis-cli --rdb手动触发RDB，避开高峰期；或用SAVE替代BGSAVE（仅限低流量从节点） - 拆分大key：用
SCAN+LRANGE/HGETALL检出 >1MB的hash/list/set，拆成带分片后缀的多个key - 禁用
stop-writes-on-bgsave-error yes，避免RDB失败后写阻塞引发雪崩，但必须配合监控告警rdb_last_bgsave_status:err - 若用AOF+RDB混合持久化（
aof-use-rdb-preamble yes），确保auto-aof-rewrite-percentage不设过低（如20%），否则频繁rewrite也会fork
为什么“预留50%内存”在容器环境尤其危险
容器（尤其是K8s）里 cgroup memory limit 和宿主机 /proc/meminfo 看到的内存不一致。Redis进程看到的是宿主机总内存，但COW实际受限于cgroup限额。此时预留50%可能直接超limit被OOMKilled——必须用 memory.limit_in_bytes 值来算，且留出至少30% buffer给COW和内核页表开销。
最容易被忽略的一点：COW压力不只来自数据写入，也来自Redis内部操作——比如 EXPIRE 批量清理、MEMORY PURGE、甚至 CLIENT LIST 返回大量连接信息，都可能隐式触发内存页修改。别只盯着业务写QPS。
