Redis推荐将maxmemory设为物理内存的70%–80%，核心原因是保障fork()操作成功：RDB快照和AOF rewrite需fork子进程，依赖Linux写时复制（COW）机制，若无足够余量，fork会因内存不足失败，导致持久化中断。
Redis 推荐将 maxmemory 设为物理内存的 70%–80%，核心原因不是“预留空间给系统进程”这么笼统，而是为了给 fork() 操作留出足够、确定的内存余量——尤其是 RDB 快照和 AOF rewrite 这两类必须 fork 子进程的操作。
为什么 fork 会突然吃掉一倍内存？
Redis 主进程在执行 SAVE 或 BGSAVE（RDB）以及 BGREWRITEAOF 时，会调用 fork() 创建子进程。Linux 的写时复制（Copy-on-Write, COW）机制会让子进程初始共享父进程的页表，但一旦主进程或子进程修改任意内存页，该页就会被完整复制一份。
这意味着：如果主进程在 fork 后持续写入（比如接收大量新请求），它可能在几秒内触发成百上千页的复制，实际内存占用可能瞬间接近 maxmemory 的 2 倍。若此时系统总内存刚好被 maxmemory 占满，fork() 就会失败，日志里出现 Can't save in background: fork: Cannot allocate memory。
常见错误现象：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
redis-cli INFO memory | grep mem_fork显示mem_fork长期 > 0 且数值接近used_memory - RDB 自动保存失败，
redis.log中反复报fork() failed - AOF rewrite 被跳过，
aof_rewrite_in_progress一直为 0，但aof_current_size持续暴涨
75% 是怎么算出来的？
这个比例不是拍脑袋定的，而是基于典型生产负载下的安全冗余估算：
- Redis 实际使用的内存（
used_memory）通常略低于maxmemory，尤其启用了淘汰策略后 - fork 后子进程至少需要等量的干净内存空间来承载 COW 页复制（最坏情况是全部页都被修改）
- 操作系统本身需约 10% 内存运行（内核、SSH、监控 agent 等）
- 预留 10%–15% 给 COW + OS，即 75% 上限 —— 这个数字在 8GB–64GB 物理内存机器上实测稳定性最高
例如：一台 32GB 内存服务器，设 maxmemory 24gb（75%），即使主进程已用 23GB，剩余 9GB 仍足以支撑 fork 后的复制压力，不会因 fork() 失败中断持久化。
配置时容易忽略的三个硬约束
光设对 maxmemory 不够，还得配合以下设置才能真正规避 fork 失败：
-
关闭 transparent huge pages（THP）：Linux 默认启用 THP 会显著增加 fork 开销，导致更频繁的内存分配失败；必须在系统级禁用：
echo never > /sys/kernel/mm/transparent_hugepage/enabled -
确保 vm.overcommit_memory = 1：否则内核在 fork 前会严格检查是否有足够空闲内存（而非依赖 COW），直接拒绝 fork；
sysctl vm.overcommit_memory=1允许乐观分配 -
避免在高峰写入期手动触发 BGSAVE：业务高峰期主进程内存变更剧烈，此时 fork 风险最高；应依赖
save配置项的自动策略，或错峰执行
真正卡住 Redis 持久化的，往往不是数据量大，而是 fork() 那一瞬间没拿到内存。75% 这个数字背后，是 Linux 内存管理机制与 Redis 架构耦合产生的刚性约束——它不灵活，但必须尊重。
