根本原因是cow机制被大key触发大量页复制；大key占据密集内存区域，高频修改导致内核频繁分配复制4kb页，rss瞬时飙升近两倍，非redis泄露而是cow必然开销。
Redis fork时内存激增的根本原因是COW机制被大Key触发大量页复制
Redis执行BGSAVE或bgrewriteaof时，必须调用fork()创建子进程。这个操作本身不拷贝物理内存，而是依赖Linux的写时复制（COW）：父子进程共享页表映射，只有当某页被修改时，内核才为该页分配新物理内存并复制内容。
问题出在大Key上——它往往占据连续、密集的内存区域（比如一个500MB的hash），且高频读写会持续触发页修改。此时内核不得不为每一个被修改的4KB页单独分配+复制，导致RSS（常驻集大小）在数秒内飙升，甚至逼近两倍峰值内存。这不是Redis“泄露”，而是COW在真实负载下的必然开销。
-
latest_fork_usec在INFO persistence中持续 >1000000（即1秒）是明确信号 - Linux
dmesg出现Out of memory: Kill process redis-server说明已触发OOM Killer -
used_memory_peak_human突增 +mem_fragmentation_ratio>1.5，说明碎片加剧了COW压力
为什么MEMORY USAGE比DEBUG OBJECT更准？
很多人用DEBUG OBJECT看serializedlength来估算Key大小，但这是错的——它只反映序列化后的字节长度，完全忽略Redis内部编码开销、哈希表扩容冗余、指针数组、内存对齐等真实占用。一个10MB的hash，DEBUG OBJECT可能报8MB，而MEMORY USAGE会返回12MB+，这才是fork时真正要复制的量。
实操建议：
- 定位大Key必须用
MEMORY USAGE <key></key>，不是DEBUG OBJECT - 批量扫描用
redis-cli --bigkeys -i 0.1，但仅作初筛；最终确认一定要对候选Key逐个跑MEMORY USAGE - 注意
MEMORY USAGE本身是阻塞命令，别在高峰对疑似大Key直接执行，先用SCAN抽样再定向查
混合持久化（RDB+AOF）会让大Key压力翻倍
启用aof-use-rdb-preamble yes后，AOF重写会先写一段RDB格式的preamble，再追加增量AOF命令。这意味着：同一个大Key，既要被RDB preamble全量序列化一次（需fork），又要在后续AOF部分再处理一遍增量变更（仍需遍历+序列化）。CPU和内存压力不是叠加，是乘性放大。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
更危险的是：CONFIG SET aof-use-rdb-preamble yes会**强制触发一次AOF重写**，没有回退路径。线上大Key实例大概率直接OOM。
- 生产环境如无强一致性要求，直接禁用：
CONFIG SET aof-use-rdb-preamble no - 禁用后记得
CONFIG REWRITE落盘，避免重启恢复时又加载旧配置 - 不要动态开关混合模式——调整必须安排在低峰期重启实例
透明大页（THP）会让COW问题雪上加霜
系统开启transparent_hugepage（THP）时，内核会尝试把多个4KB页合并成2MB大页。但Redis内存分配高度动态、不连续，THP反而导致频繁的页分裂、内存规整（compaction）和TLB miss，进一步拉长fork()耗时，并加剧内存碎片。
检查方式：cat /sys/kernel/mm/transparent_hugepage/enabled，若输出含[always]或[madvise]，就必须关：
- 临时关闭：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 同时关后台整理：
echo never > /sys/kernel/mm/transparent_hugepage/defrag - 永久生效需写入启动脚本或systemd drop-in，否则重启失效
最易被忽略的一点：即使你拆分了大Key、关了THP、调了vm.overcommit_memory = 1，只要mem_fragmentation_ratio长期高于1.5，COW压力依然会隐性放大——这时候不是配置问题，是内存碎片已到临界点，必须安排主从切换后重启实例释放内存。
