根本原因是透明大页（THP）导致fork时页表拷贝耗时激增，启用THP后COW开销放大512倍，引发数百毫秒卡顿；须永久禁用THP（enabled与defrag均设为never）、验证smaps无2048kB页、重启Redis生效。
Redis fork耗时高，根本原因不是RDB或AOF慢，而是THP干扰了页表拷贝
Redis执行bgsave或bgrewriteaof时主线程卡顿几百毫秒，90%以上情况和磁盘IO、CPU无关，而是Linux内核在fork子进程时复制页表被透明大页（THP）拖累。启用THP后，原本4KB的小页被合并为2MB大页，fork需处理更少但更重的页表项，但一旦发生写时复制（COW），单次内存页分裂开销放大512倍——这直接导致延迟毛刺、慢查询突增，甚至incr这类简单命令都进slowlog。
禁用THP不能只改/sys/kernel/mm/transparent_hugepage/enabled
临时执行echo never > /sys/kernel/mm/transparent_hugepage/enabled只是表面生效，必须同步关闭defrag，否则后台khugepaged线程仍会强行合并页：
echo never > /sys/kernel/mm/transparent_hugepage/enabledecho never > /sys/kernel/mm/transparent_hugepage/defrag
验证是否真关掉，不能只信cat /sys/kernel/mm/transparent_hugepage/enabled输出[never]——要查Redis主进程的/proc/<pid>/smaps</pid>：
- 先用
ps aux | grep redis-server拿到PID - 再执行
grep -i "mmupage\|mmupf" /proc/<pid>/smaps | head -10</pid>
正常应全是MMUPageSize: 4 kB；若出现大量2048 kB，说明THP仍在后台生效，常见于MySQL、Java服务启动脚本悄悄启用了它。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
容器和云主机环境要额外防tuned或cgroup干扰
在AWS EC2、阿里云ECS或Kubernetes Pod里跑Redis，即使你手动关了THP，也可能被系统级调优工具覆盖：
- AWS默认AMI常预装
tuned，它的virtual-guest或throughput-performanceprofile会重开THP，得运行sudo tuned-adm off并禁用服务 - 容器中若设了
memory.limit_in_bytes，cgroup v1下fork可能触发内存规整（compaction），加剧延迟；建议用cgroup v2 +memory.high替代硬限 - 某些CentOS 8.5+系统已弃用
/etc/rc.local，必须用systemd服务方式持久化禁用THP，例如创建/etc/systemd/system/disable-thp.service并systemctl enable disable-thp
THP只是起点，不配套调其他参数照样卡
关了THP但还卡？大概率是以下三项没跟上：
-
vm.swappiness=0：避免fork后子进程首次写入触发swap，检查cat /proc/sys/vm/swappiness -
overcommit_memory=1：设为1允许内核乐观分配内存，防止fork前因overcommit检查失败而拒绝fork（尤其大内存实例） - SSD是硬门槛：机械盘上
bgsave耗时可能从200ms飙到2s以上，且I/O不可控，别指望调参能救
真正容易被忽略的是：THP禁用后，/proc/<pid>/smaps</pid>里MMUPFPageSize字段可能仍显示2048 kB——这意味着进程启动时已被THP映射，必须重启Redis才能清空旧页表。不重启，所有调优都是隔靴搔痒。
