rdb/aof重写导致rss翻倍主因是linux fork()后的写时复制（cow）机制：主线程修改内存页时内核需复制整页（4kb），高频写入+bigkey触发大量页复制，使used_memory_rss短时逼近2×used_memory；maxmemory须预留cow余量，16gb物理内存建议maxmemory≤10gb，32gb≤20gb，容器环境额外预留≥2gb，禁用maxmemory 0及主节点save配置，改由从节点低峰期执行持久化。

为什么RDB/AOF重写会让RSS翻倍

不是Redis在“吃”内存，而是Linux fork() 后的写时复制（COW）机制导致：子进程初始共享页表，但主进程每改一个内存页，内核就复制整页（4KB）。高频写入+大key=大量页被复制，used_memory_rss 很快逼近 2 × used_memory。若此时 maxmemory 设到总内存80%，几乎必然触发OOM Killer。

maxmemory必须预留COW余量

把 maxmemory 当作“数据集上限”是最大误区。它实际要为COW留出安全空间：

• 16GB物理内存 → maxmemory 不超过 10GB（62.5%），高压场景压到 8GB 更稳
• 32GB机器 → 别直接按比例设25GB，建议 ≤ 20GB
• 容器环境 → 额外预留 ≥ 2GB 给 pause 容器、cgroup 开销
• 绝对禁止 maxmemory 0，这是生产环境最常见OOM诱因

动态调整后务必执行 CONFIG REWRITE，否则重启失效。

禁用自动save，改由从节点低峰期执行

主节点上 save 配置（如 save 60 10000）会主动触发 bgsave，和业务写入撞在一起，COW压力雪上加霜：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 主节点关闭所有 save 行，设为 save ""
• 让从节点在业务低峰期（如凌晨）执行 bgrewriteaof 或 bgsave，主节点只做写入
• 用 redis-cli -h slave-ip config set save "3600 1" 单独配置从节点，避免影响主服务

注意：从节点执行 bgsave 仍会 fork，但它不承接写流量，COW压力远低于主节点。

拆大key + 控制写入节奏

一个500MB的 HASH 每秒改100个字段，等于每秒触发上百次页复制。这不是调参能解决的，必须动数据结构：

• 用 redis-cli --bigkeys 扫描，重点盯 hash、list、zset 类型的“炸弹key”
• 把单个大 HASH 拆成多个带分片标识的key，如 user:1001:profile:0 ~ :3
• 批处理任务避开RDB/AOF窗口：用 redis-cli config get save 查当前策略，错开高峰期写入
• 临时压降可配合 CONFIG SET stop-writes-on-bgsave-error no，但只是防失败，不减内存压力

COW是操作系统层行为，没法绕过。真正可控的只有三件事：给它留够空间、别让它在忙时干活、别拿单个超大内存块去反复捅它。