redis主线程阻塞源于fork()内核级同步操作，需复制页表、初始化vma等，内存超10gb且启用thp时耗时易超500ms，期间完全无法处理命令。
因为 fork() 本身会阻塞 Redis 主线程，且耗时随内存增长非线性放大；卡顿不是“偶尔抖动”，而是主线程在内核态完成页表复制期间完全停摆。
fork() 阻塞的实质是内核级同步操作
Redis 的 bgsave 和 bgrewriteaof 都依赖 fork() 创建子进程。虽然写时复制（COW）不立即拷贝物理内存，但内核必须同步完成页表项（PTE）复制、VMA 结构初始化、内存映射扫描——这些都在主线程上下文中执行，不可并发。
- 当
used_memory_rss超过 10 GB，尤其开启transparent_hugepage时，latest_fork_usec极易突破 500000（500ms），实测 20 GB 实例常达 800ms+ - 此期间 Redis 完全无法处理任何客户端命令，
SLOWLOG无记录（命令根本没进执行队列） -
INFO persistence中该值持续 >300000 就已属高风险，>800000 表明系统已严重失稳
频繁触发会形成“快照风暴”
自动 save 规则（如 save 60 10000）与 auto-aof-rewrite-percentage 若配置不当，会在写入高峰时段密集撞车：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 刚结束一次
bgsave，下一秒又因写入量达标触发新bgsave，或同时启动bgrewriteaof - 两个后台子进程争抢 CPU 缓存、TLB 条目和磁盘 IO，
instantaneous_ops_per_sec断崖下跌 -
mem_fork_ratio接近或超过 2.0，说明 fork 开销已占主线程有效时间一半以上
容器/云环境会显著放大 fork 延迟
虚拟化层引入的额外约束会让问题更隐蔽也更顽固：
- cgroup 内存限制下，
fork()可能因内核检查失败直接返回Cannot allocate memory（即使free -h显示内存充足） - qcow2、thin-LVM 等虚拟存储栈会加深 page fault 栈，导致 TLB 污染加剧，fork 耗时标准差比裸设备高 3–5 倍
- 未禁用
transparent_hugepage时，内核强制拆分 huge page，页表项操作量暴增——哪怕内核是 5.15，优化也被绕过
真正容易被忽略的点
很多人调低了 save 频率、关了 AOF，却发现卡顿依旧。问题往往不在 Redis 配置本身，而在操作系统层：
-
vm.overcommit_memory = 0（默认值）是最大隐患：它让 fork 在物理内存不足时直接失败，而 COW 场景下其实完全可安全允许 -
/sys/kernel/mm/transparent_hugepage/enabled必须设为never，且该设置需写入开机脚本，重启即失效 -
vm.swappiness = 0不只是防 swap，更是避免 fork 时因缺页重试引发的不可预测延迟延长
