设 vm.overcommit_memory = 1 可绕过 fork 失败，因内核跳过内存承诺检查、启用 COW；但必须同步禁用 THP、为 COW 预留 maxmemory 余量，三者缺一不可。
直接设 vm.overcommit_memory = 1 是最有效手段，但它必须和禁用透明大页（THP）、控制 maxmemory 预留余量三者同时生效，缺一不可。
为什么 vm.overcommit_memory = 1 能绕过 fork 失败
Redis 执行 bgsave 或 bgrewriteaof 时会调用 fork()。Linux 默认 vm.overcommit_memory = 0，内核在 fork 前会做启发式检查：是否“能承诺”给子进程足够物理内存（哪怕子进程只读）。检查失败就直接报 Cannot allocate memory。设为 1 后，内核跳过该检查，“先 fork，按需分配”，让 COW 真正起作用。
常见错误现象包括：
- 日志反复出现
Can't save in background: fork: Cannot allocate memory -
redis-cli info memory中used_memory_rss突然翻倍，但used_memory几乎不变 - 系统
free -h显示空闲内存充足，Redis 却持续 fork 失败
实操建议：
- 临时生效：
echo 1 > /proc/sys/vm/overcommit_memory - 永久生效：在
/etc/sysctl.conf加vm.overcommit_memory = 1，再执行sysctl -p - 绝对不要设为 2：它依赖
overcommit_ratio计算硬上限，在 COW 场景下更容易触发 OOM killer
为什么必须禁用透明大页（THP）
即使 vm.overcommit_memory = 1 生效，若 THP 仍开启，khugepaged 后台线程会持续扫描 Redis 进程的匿名内存页，试图合并为 2MB 大页。而 Redis 内存访问高度随机、写入频繁，THP 不仅无效，还会加剧页表分裂、增加 COW 开销，导致 used_memory_rss 比预期高 30%–50%。
确认是否启用 THP：
-
cat /sys/kernel/mm/transparent_hugepage/enabled输出含[always]或madivse即表示启用 - 禁用命令：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 同时检查并禁用 defrag：
echo never > /sys/kernel/mm/transparent_hugepage/defrag
注意：这些设置重启失效，需写入 /etc/rc.local 或 systemd drop-in 文件中固化。
maxmemory 必须为 COW 预留真实余量
COW 不是理论开销，是实实在在的物理内存占用。若 maxmemory 设为总内存的 80%，RDB/AOF 重写期间 used_memory_rss 很可能突破物理内存上限，触发 OOM killer 杀掉 redis-server。
推荐设置：
- 16GB 物理内存服务器：
maxmemory≤ 10GB（62.5%），压力大时压到 8GB - 32GB 机器不建议超过 20GB；容器环境额外预留 ≥2GB 给 pause 容器和 cgroup 开销
- 绝对不要设
maxmemory 0—— 生产环境最常见崩溃诱因之一
验证方式：
- 运行
INFO memory，比对used_memory_peak和maxmemory差值，建议保留 ≥25% 余量 - 用
redis-cli --bigkeys扫描是否存在单个 Hash 占几百 MB 的“炸弹 Key” - 若
mem_fragmentation_ratio > 1.5，先执行MEMORY PURGE清碎片，再评估余量
BigKey 和写入节奏是 COW 压力放大器
一个 500MB 的 Hash 每秒改 100 个字段，会持续触发整页复制；不是因为 Key 大，而是修改行为迫使内核复制整页（4KB 或更大粒度）。多个 BigKey 并发更新，used_memory_rss 可在 10 秒内飙升 80% 以上。
缓解手段：
- 拆分大 Key：把单个大 Hash 改成多个小 Hash，或用 Sorted Set 分片
- 错峰写入：批处理任务避开
save触发时间窗口；高频写场景可临时切淘汰策略为volatile-random减少 LRU 计算开销 - 关闭不必要的持久化：热数据节点可关
save，由从节点低峰期执行 RDB
真正危险的从来不是“内存够不够”，而是“COW 是否在你没意识到的时候悄悄吃掉了最后那 2GB”。used_memory_rss 才是 OOM killer 真正盯的指标，它不骗人，也不给你第二次机会。
