Redis RDB fork卡顿的根本原因是Linux内核启用THP后，fork()需扫描复制大量2MB大页，导致主线程秒级停顿；须在系统层永久关闭THP（如GRUB加transparent_hugepage=never），并配合调整save策略、禁用AOF重写叠加、设置vm.overcommit_memory=1等措施。
Redis RDB fork卡顿的根本原因在哪
不是 Redis 本身慢，而是 fork() 系统调用在内存大、THP（Transparent Huge Pages）开启时会扫描并复制大量匿名页，导致主线程长时间停顿（有时达秒级）。尤其在物理内存超 32GB、RDB 文件 > 2GB 的场景下，卡顿更明显。
关键点：Linux 内核的 THP 默认启用后，会把原本 4KB 的内存页合并成 2MB 大页；而 fork() 需要为每个子进程建立页表副本——大页越多，复制开销越大，且容易触发写时拷贝（COW）抖动。
怎么关掉 THP（永久生效）
必须在操作系统层关闭，Redis 配置里加任何参数都无效。THP 是内核特性，影响所有进程，不单是 Redis。
- 检查当前状态：
cat /sys/kernel/mm/transparent_hugepage/enabled，若输出含[always]或[madvise]，说明未关闭 - 临时关闭（重启失效）：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 永久关闭：在
/etc/rc.local（systemd 环境下推荐用/etc/systemd/system/disable-thp.service）中加入上述 echo 命令；或在 GRUB 启动参数加transparent_hugepage=never，再update-grub & reboot - 注意：有些云厂商（如 AWS EC2 Ubuntu 镜像）默认设为
madvise，看似“安全”，但 Redis 的malloc行为常触发 THP 合并，仍需设为never
RDB 期间还能做哪些减负操作
关 THP 是治本，但配合以下配置可进一步压低 fork 峰值负载：
- 避免高峰时段触发 RDB：
save 300 10这类低频策略比save 60 10000更稳妥，尤其当写入突增时 - 禁用
auto-aof-rewrite和 RDB 的同时发生：设置no-appendfsync-on-rewrite yes，防止 AOF rewrite 叠加 fork 压力 - 确认
vm.overcommit_memory = 1（而非 0 或 2），避免 fork 因内存预估失败直接返回 ENOMEM - 不要用
CONFIG SET save ""动态清空 save 规则——这会让已排队的 bgsave 仍执行，只是后续不触发；真正想停 RDB，得改配置+重载或直接redis-cli config rewrite后redis-cli bgrewriteaof（如果启用了 AOF）
验证是否真起效了
别只看 enabled 文件内容，得测 fork 耗时是否回落。
- 监控
INFO persistence中的rdb_last_bgsave_time_sec，稳定在 0.1s 内才算达标（之前可能 2~5s） - 用
strace -p $(pgrep redis-server) -e trace=fork,clone观察 fork 返回耗时（需在 bgsave 期间抓） - 查内核日志：
dmesg | grep -i "thp"，确认无 “THP disabled” 以外的警告 - 注意：容器环境（如 Docker）中，THP 设置需在宿主机生效，容器内
/sys是只读挂载，改不了
THP 关闭后不会影响 Redis 内存使用量或命中率，但 fork 稳定性会立刻改善。最容易被忽略的是——很多运维只改了 Redis 配置、调了 client-output-buffer-limit，却没碰系统层，结果卡顿照旧。
