根本原因是fork子进程时COW机制导致内存瞬时翻倍，系统空闲内存不足触发OOM Killer；应调低maxmemory预留缓冲、设vm.overcommit_memory=1、禁用THP，并评估集群拆分。
Redis启动加载大RDB时被OOM Killer杀掉怎么办
根本原因不是“加载慢”，而是fork子进程时写时复制（COW）触发内存翻倍申请，系统没足够空闲内存，内核直接用OOM Killer干掉redis-server进程。日志里出现Can't save in background: fork: Cannot allocate memory或进程突然消失但无ERROR日志，基本就是它。
实操要点：
- 查
free -h和cat /proc/meminfo | grep -i "memavailable\|commit"，确认MemAvailable是否远小于RDB文件大小的1.5倍（RDB解压后内存占用≈原始大小×1.2～1.8） - 临时绕过：改
vm.overcommit_memory=1（允许overcommit），再重启；但只是掩耳盗铃，不能解决真实内存不足 - 真正有效的是降
maxmemory——比如RDB实际数据量15GB，就把maxmemory设为16GB，留出缓冲空间，避免fork时申请失败 - 禁止在低配VPS或内存紧张的宿主机上存数十G RDB；这类实例应禁用持久化：
save ""+appendonly no
加载卡在“Loading DB”几十秒不动，strace显示read()阻塞
说明瓶颈在磁盘读取，不是解析。尤其常见于机械盘、NFS挂载卷、或启用了透明大页（THP）的系统。
验证与处理：
- 用
strace -p $(pgrep redis) -e trace=read,openat 2>&1 | grep read观察是否长时间停在某次read()调用上 - 用
dd if=dump.rdb of=/dev/null bs=1M测裸盘顺序读速度；若低于50MB/s（SSD应≥300MB/s），说明IO是瓶颈 - 检查挂载参数：
mount | grep $(df . | tail -1 | awk '{print $1}')，避免noatime,nodiratime之外还加了sync或barrier=1 - 关闭THP：
echo never > /sys/kernel/mm/transparent_hugepage/enabled（需加到/etc/rc.local持久化）
加载过程中从节点反复断连，INFO replication状态循环connect→sync→disconnected
这不是从节点的问题，是主节点主动踢人——因为client-output-buffer-limit slave超限。大RDB传输时间长，主节点输出缓冲区积压，触发默认的256mb 64mb 60策略。
必须做三件事：
- 先确认：
CLIENT LIST里找该从节点行，看omem是否持续＞60MB；再查主节点日志有没有Client closed connection due to output buffer limit - 调参示例（20GB RDB，千兆网）：
CONFIG SET client-output-buffer-limit "slave 40gb 20gb 300"，其中300是秒级超时，要大于RDB大小 ÷ 带宽 - 同步写入
redis.conf，否则重启失效；多从节点场景下，总缓冲区压力 = 单节点上限 × 从节点数，别只看单个
加载成功但内存不释放，dbsize正常但RES持续高位
Redis加载完RDB不会立刻归还物理内存给系统，尤其是碎片率高时。现象是top里RES居高不下，但INFO memory中used_memory_rss和used_memory比值＞2.5，且mem_fragmentation_ratio＞1.5。
这不是bug，但会影响后续fork：
- 不要等它自动整理——Redis没有运行时内存整理机制
- 紧急缓解：执行
MEMORY PURGE（Redis ≥ 6.0，仅对jemalloc有效） - 长期方案：升级到Redis 7.0+并启用
activedefrag yes，配合active-defrag-threshold-lower 10等参数 - 最稳妥方式：滚动重启——先切走流量，
DEBUG RELOAD（慎用）或停机重启，让内存彻底重置
真正难处理的从来不是“怎么加快加载”，而是搞清哪一环在吃内存、哪一层在卡IO、哪个配置在静默干预。几十GB RDB已经超出单实例常规运维边界，得从部署架构上重新评估：是不是该拆分集群？是不是该用Redis Stack替代纯缓存角色？
