THP使fork()耗时翻倍以上，因其将4KB小页合并为2MB大页，虽减少页表项数量，但加深页表层级、加剧TLB失效，且fork需为每个大页构建独立映射，同步开销陡增；同时khugepaged后台扫描持续争抢mmap锁，进一步延长阻塞时间。
为什么THP会让fork()耗时翻倍甚至更高
因为Redis的fork()本身不拷贝内存页数据，但必须复制页表结构；开启THP后，内核把原本4KB的小页合并成2MB大页，导致页表项数量锐减、单个页表项管理范围暴增——而fork()过程仍需为每个大页构造独立映射，实际要操作的页表层级更深、TLB失效更频繁，同步开销陡增。
THP干扰COW机制的真实表现
fork()完成后，Redis主线程和子进程共享物理内存只读映射；一旦主线程执行INCR或SET，就会触发写时复制（COW）。此时问题暴露：不是复制4KB，而是整块2MB大页被复制。一次简单写入可能引发2MB内存分配+拷贝，延迟从微秒级跳到毫秒级，且会连带触发khugepaged后台扫描，进一步争抢mmap锁。
-
INFO persistence中latest_fork_usec值飙升（如从100ms跳到800ms+） -
SLOWLOG GET 10里大量基础命令超时，但slowlog get查不到慢命令来源 - 用
strace -p $(pgrep redis-server) -e trace=clone,fork可见fork返回后紧接大量write系统调用毛刺
为什么只关enabled还不够
即使/sys/kernel/mm/transparent_hugepage/enabled设为[never]，若defrag仍是[always]或[madvise]，内核线程khugepaged仍会持续扫描Redis进程的匿名内存页，尝试合并为大页。这个过程会持有mmap锁、干扰内存映射，间接拉长fork耗时。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须同时检查两个路径：
cat /sys/kernel/mm/transparent_hugepage/enabled和cat /sys/kernel/mm/transparent_hugepage/defrag - RHEL/CentOS 6+用户还得额外检查
/sys/kernel/mm/redhat_transparent_hugepage/enabled，因路径被发行版重命名 - 容器环境若挂载
/sys为只读，echo never > ...会失败，需在宿主机层面禁用
验证THP是否真正退出的硬指标
别信Redis日志有没有WARNING，也别只看cat /proc/meminfo | grep AnonHugePages是否为0——它可能滞后。最直接的验证是：
-
rdb_last_bgsave_time_sec回归正常（≤0.1s），且不再周期性突增至2~5s - 重启Redis后，
latest_fork_usec稳定在100ms以内（16GB实例，内核5.15+） -
cat /proc/<pid>/smaps | grep -i huge</pid>输出中AnonHugePages为0，且无mm_struct相关锁等待
复杂点在于：tuned服务、cgroup v1内存限制、甚至GRUB启动参数都可能覆盖你的设置。生产环境必须用systemd service方式固化，并在每次系统更新后复查。
