Redis RDB快照生成失败时bgsave返回ERR，主因是fork()系统调用失败，典型表现为日志中出现“Failed to fork() for RDB: Cannot allocate memory”或“Resource temporarily unavailable”，根本原因在于Linux的vm.overcommit_memory设置不当（默认0易拒绝fork）、内存压力过大、ulimit -u或pid_max耗尽，或cgroup内存限制过严；应将vm.overcommit_memory设为1并检查cgroup限制。
Redis RDB快照生成失败时，bgsave 返回 ERR 的典型表现
Redis 启动 bgsave 后没生成 dump.rdb，客户端收到 ERR Background save failed，日志里紧跟着出现 Failed to fork() for RDB: Cannot allocate memory 或 Cannot fork: Resource temporarily unavailable。这不是 Redis 本身 bug，而是 fork() 系统调用失败 —— 子进程根本没起来，自然没有快照。
- 这类错误几乎都发生在 Linux 上，和
/proc/sys/vm/overcommit_memory设置强相关 - 即使物理内存充足，内核也可能因 overcommit 策略拒绝
fork()（因为 Redis 主进程内存映射页多，fork()需预留等量虚拟地址空间） -
ulimit -u（用户进程数限制）或pid_max耗尽也会触发Resource temporarily unavailable
检查 vm.overcommit_memory 和实际内存压力
Redis RDB 依赖 fork() 创建子进程，而子进程初始共享父进程页表，但写时复制（COW）。内核是否允许这次 fork()，取决于 vm.overcommit_memory 的值：
-
0（默认）：启发式判断，对大内存 Redis 很容易拒绝 -
1：总是允许fork()，风险是 OOM killer 可能杀掉进程（但对 Redis 是可接受的权衡） -
2：严格检查可用内存 + swap，需同步调大vm.overcommit_ratio
运行 cat /proc/sys/vm/overcommit_memory 查当前值；若为 0，建议改为 1：echo 1 > /proc/sys/vm/overcommit_memory（加到 /etc/sysctl.conf 持久化）。
同时看 free -h 和 cat /proc/meminfo | grep -i "commit"，确认 CommitLimit 是否接近 Committed_AS —— 接近即说明 overcommit 已绷紧。
bgsave 失败但没报错内存？查 fork() 被信号中断或 cgroup 限制
有些情况日志里看不到内存相关提示，只写 Background saving error 或干脆静默失败。这时要盯住系统层：
-
dmesg -T | grep -i "killed process"：OOM killer 是否干掉了redis-server子进程（常见于容器或 cgroup 内存限制过严） -
cat /sys/fs/cgroup/memory/redis*/memory.limit_in_bytes（如果用了 cgroup v1）或systemctl show redis | grep MemoryMax（cgroup v2）：确认没把 Redis 进程内存上限设得比实际占用还低 -
strace -p $(pgrep redis) -e trace=fork,clone（临时抓一下）：观察fork()是否返回-1并设errno=12（ENOMEM）或其他值
容器环境尤其注意：Docker 默认不设 --memory 时用主机 limits，但 Kubernetes Pod 若配了 resources.limits.memory，cgroup 会硬限，fork() 直接失败。
为什么不用 save 替代？它和 bgsave 的阻塞本质差异
save 是主线程同步写盘，期间 Redis 完全不可服务；bgsave 是唯一可行的生产环境快照方式。但很多人误以为“只要关掉 bgsave 改用 save 就能绕过 fork 问题”——这是错的：
-
save不触发fork()，但它会阻塞所有命令，单次耗时可能达秒级（尤其数据量大、磁盘慢时） - 频繁
save会导致客户端大面积超时，监控指标如rejected_connections会飙升 - Redis 4.0+ 的
active-defrag或 AOF rewrite 也依赖fork()，不解决根本问题只是推迟失败
真正该做的是：调 overcommit_memory、压 maxmemory 留余量、避免在高峰期手动 bgsave，以及——别让 Redis 进程本身吃掉机器 80% 以上内存。
RDB 生成失败从来不是 Redis 的配置问题，而是它把你忽略的系统约束直接摆到了台面上。最常被跳过的，是 overcommit_memory=1 这一行 sysctl 设置，和容器里那个看不见的 memory.limit_in_bytes。
