为什么Redis建议maxmemory设置不超过物理内存的75%

fork()失败才是redis持久化的真瓶颈，因rdb和aof rewrite依赖fork()，而linux cow机制要求充足连续空闲内存支撑页复制，75% maxmemory是兼顾cow开销、内存碎片与系统基础占用的实测安全线。

为什么redis建议maxmemory设置不超过物理内存的75%_预留系统缓冲区

fork()失败才是真瓶颈，不是系统卡顿

Redis设maxmemory为物理内存75%，核心不是“给系统留点内存”，而是确保fork()能成功——RDB快照和AOF rewrite都依赖它。Linux写时复制（COW）机制下，子进程初始不占新内存，但主进程一写数据，被修改的页就会被完整复制。若maxmemory设到90%，而used_memory已到8.5GB，此时fork()需要至少8.5GB干净空闲内存来承载可能的页复制，系统大概率直接报Can't save in background: fork: Cannot allocate memory。

查证方式：redis-cli INFO memory | grep -E "(used_memory|mem_fork)"，若mem_fork长期 > 0 且接近used_memory，说明COW压力已在临界点
典型错误现象：RDB自动保存失败、aof_rewrite_in_progress始终为0、日志反复出现fork() failed
不要只看free -h显示的“available”，fork()需要的是连续、未被映射的物理页，swap不能救它

75%不是经验公式，是COW+OS+碎片三重冗余估算

这个比例来自生产环境实测平衡点：假设一台32GB服务器，设maxmemory 24gb（75%），即使Redis已用23GB，剩余9GB仍要同时覆盖三类开销：

mem_fragmentation_ratio通常在1.2–1.6之间，jemalloc碎片会让RSS比used_memory高5–10GB
系统基础开销（systemd、rsyslog、sshd、监控agent）在Debian/Ubuntu上轻松吃掉700MB–1GB
AOF rewrite期间子进程需额外缓冲区，尤其当aof_rewrite_incremental_fsync关闭时，临时内存峰值更陡峭

超过75%就一定炸？得看你的持久化模式和负载特征

75%是通用安全线，但可微调的前提是你清楚自己在压哪根弦：

Redis 8.2.3

Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。

下载

纯缓存 + no-appendfsync-on-rewrite yes + 关闭RDB → 可试探性提到80%，但必须监控mem_fork_bytes和evicted_keys突增
启用了activerehashing yes且key数超千万 → 哈希表渐进式rehash会额外申请内存，建议回落到65%–70%
使用memory allocator jemalloc且maxmemory-policy allkeys-lru → 淘汰本身不释放物理内存，RSS下降滞后，预留空间要更厚