RedisBGSAVE防淘汰，COW与内存冗余解析

Redis在执行BGSAVE时因fork子进程触发Copy-On-Write（COW）机制，导致父进程修改内存页时瞬时复制大量物理内存页，若此时已接近maxmemory上限，RSS内存骤增便会直接触发布局淘汰（evicted_keys飙升）——这并非淘汰策略缺陷，而是COW引发的隐性内存膨胀所致；通过监控/proc/PID/statm中的WriteCopy值可精准识别COW压力，结合预留15%~25%内存冗余、优化写操作模式（避免高频小更新与大value部分写）、定期清理残留大key及合理使用active-defrag，才能在保证数据持久化的同时维持内存确定性，而简单切换为noeviction策略反而可能引发写入阻塞的更严重业务故障。

Redis 在 bgsave 期间触发大量 evicted_keys，根本原因不是淘汰策略本身有问题，而是 COW 导致 RSS 内存暴涨，触碰 maxmemory 上限后被迫淘汰——这不是“该不该淘汰”，而是“内存被 COW 吃光了”。

为什么 bgsave 会突然拉高淘汰数？

执行 bgsave 时，Redis fork 出子进程，内核启用 Copy-On-Write。父进程每修改一个内存页，就复制一页物理内存。若此时内存已接近 maxmemory，COW 引发的瞬时内存增长会直接越过阈值，触发淘汰逻辑（尤其是 volatile-lru 或 allkeys-lru 等策略）。

常见诱因包括：

• 高频小 key 更新（如计数器 INCR）——看似轻量，但每个修改都可能触发一页复制
• 大 value 的部分写（如对 10MB 的 HASH 执行单个 HSET）——只改一个字段，却复制整页
• DEL + SET 替换大 key ——旧对象未立即释放（lazyfree 未完成），新对象又占内存，COW 雪上加霜

如何用 INFO memory 和 /proc//statm 实时判断 COW 压力？

别看 top 或 ps 的 RSS：它们显示父子进程总和，无法分离 COW 开销。真正关键的是：

• 先获取主进程 PID：redis-cli INFO server | grep process_id
• 查 /proc//statm 第六列（WriteCopy），单位是内存页数
• 乘以 getconf PAGESIZE（通常为 4096）得字节数
• 若该值在几秒内从 0 跳到 >500MB，说明正在密集复制脏页——此时 evicted_keys 必然飙升

同时观察 INFO stats 中的 evicted_keys 和 expired_keys：若二者在 bgsave 开始后突增，基本可确认是 COW 挤占内存所致。

保留多少内存冗余才够安全？

没有固定百分比，取决于你的写负载特征和实例大小。实测经验：

• 64GB 实例，写入压力中等（QPS ~2k），建议预留 ≥15%（即至少 9.6GB）不计入 maxmemory
• 若存在大量 >1MB 的 hash/list/set，或频繁 HSET/HMSET，冗余需提高至 20–25%
• 用 MEMORY USAGE 定期扫描，识别“逻辑已删、物理未释放”的大 key，它们会持续占用冗余空间
• 启用 active-defrag 可缓解碎片导致的虚假内存紧张，但不能替代真实冗余

为什么 noeviction 不是万能解？

设 maxmemory-policy noeviction 确实能阻止淘汰，但代价是：一旦 COW + 当前写入突破 maxmemory，后续写命令直接返回 (error) OOM command not allowed when used memory > 'maxmemory'.。业务是否能容忍这种硬失败，比“丢几个 key”更难评估。更务实的做法是：保留冗余 + 控制写行为 + 拆分实例，三者配合，而非依赖单一策略。

COW 的本质是时间换空间，而 Redis 生产环境最缺的往往既不是时间，也不是空间，是确定性——那些在 bgsave 秒级窗口里突然翻倍的内存页，才是真正咬人的地方。

以上就是《RedisBGSAVE防淘汰，COW与内存冗余解析》的详细内容，更多关于的资料请关注golang学习网公众号！