Redis启动加载RDB时内存开销达文件大小2–3倍，主进程解析构建数据结构、元数据及过期字典，叠加COW与jemalloc碎片（mem_fragmentation_ratio常超1.8），导致RSS飙升；系统vm.overcommit_memory=2会直接fork失败。
Redis启动时RDB加载触发OOM的真实内存开销
Redis加载RDB文件时，实际内存占用可能达到文件大小的2–3倍，远超used_memory指标显示值。这不是配置错误，而是COW（Copy-On-Write）机制+解析过程双重叠加的结果。
主进程读取RDB时需构建完整数据结构，同时为每个键分配元数据、计算哈希槽、初始化过期时间字典；而fork出的子进程虽不参与加载，但加载过程本身会大量申请临时内存（如解压缓冲、对象转换中间态），这些内存不会计入maxmemory限制，却真实消耗物理内存。
- RDB文件1GB → 启动加载期间RSS可能冲到2.4GB以上（尤其含大量小key或嵌套结构）
- jemalloc在高压力下内存分配碎片率升高，
mem_fragmentation_ratio常突破1.8，进一步放大实际占用 - 若系统开启
vm.overcommit_memory=2，内核拒绝fork，直接导致Redis无法启动，日志仅显示Fork operation failed，无OOM字样
为什么AOF重写比RDB加载更容易OOM
AOF重写是Redis主动触发的内存敏感操作，其风险集中在“边写边复制”阶段：子进程需遍历当前全部键空间生成新AOF，同时主进程持续写入——这导致两份键空间元数据并存，且AOF缓冲区（aof_rewrite_buf_blocks）会随写入量线性增长。
典型表现是INFO memory中used_memory_rss飙升，但used_memory变化不大；此时client-output-buffer-limit和repl-backlog-size若未调优，会进一步抢占内存余量。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- AOF重写期间，
redis-cli info memory | grep mem可见used_memory_peak突增30%~50% - 重写使用
fork()，低内存VPS上极易失败，错误日志为Can't rewrite append only file: fork: Cannot allocate memory - 即使重写成功，新AOF文件首次加载仍要走一遍RDB式解析流程，二次冲击内存
排查启动OOM是否由持久化文件引发的关键命令
别等Redis卡死再查，启动前用离线方式预估RDB/AOF加载压力：
- 查RDB文件逻辑大小：
redis-check-rdb --stat dump.rdb，关注keys总数与avg_key_len，>100万key且平均长度>64B时需警惕 - 估算AOF重写后体积：
redis-cli info persistence | grep aof_current_size，若接近maxmemory的70%，重写大概率OOM - 检查系统级限制：
cat /proc/sys/vm/overcommit_memory必须为1（允许overcommit）；free -h确认剩余内存 ≥ 2×RDB文件大小 - 验证jemalloc碎片：
redis-cli info memory | grep mem_fragmentation_ratio，>1.5说明已有隐性压力，加载前先redis-cli config set maxmemory-policy allkeys-lru释放部分缓存
生产环境避免持久化加载OOM的硬约束
没有“安全”的大文件加载方案，只有可量化的规避边界。以下数值来自多个2025–2026年线上事故复盘：
- RDB文件单个不宜超过4GB（对应约16GB物理内存预留）
- AOF文件重写前，确保
repl-backlog-size≤ 128MB，否则复制积压缓冲与AOF缓冲争抢内存 - 禁止在
maxmemory设为0（无限制）的实例上启用AOF，此时重写会耗尽全部系统内存 - 容器化部署时，cgroup memory limit必须 ≥
maxmemory+ 3GB（预留COW与解析开销），不能只按maxmemory设置
最易被忽略的一点：RDB/AOF加载时的内存峰值不可监控，INFO memory只反映加载完成后的稳定态。真正危险的是那几十秒的瞬时尖峰——它不会报错，只会让OOM Killer静默干掉Redis进程。
