必须同时禁用thp的enabled和defrag为[never]并重启redis，否则khugepaged线程仍会触发内存整理导致卡顿；需验证/sys路径及redis进程smaps中无2048kb页。
必须同时禁用 enabled 和 defrag，否则 Redis 仍会卡顿——只改一个等于没改。
检查 THP 当前状态是否真关闭
别信 Redis 日志里的 WARNING，有些系统（如 RHEL/CentOS）把路径改成了 /sys/kernel/mm/redhat_transparent_hugepage/enabled，而 Redis 只读标准路径；只要内核在后台合并页，延迟就藏不住。
- 运行
cat /sys/kernel/mm/transparent_hugepage/enabled，输出含[always]或[madvise]就说明 THP 活跃 - 同样执行
cat /sys/kernel/mm/transparent_hugepage/defrag，它也必须是[never]；只关enabled不关defrag，内核线程khugepaged仍会强行整理内存，照样卡 Redis - 容器或云主机环境（如 AWS EC2、阿里云 ECS）可能被
tuned覆盖，需额外执行sudo tuned-adm off并systemctl disable tuned
临时禁用（仅用于验证）
适合快速确认是否为 THP 导致的延迟毛刺，但重启即失效，不能用于生产。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须用 root 执行：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 同步执行：
echo never > /sys/kernel/mm/transparent_hugepage/defrag - 验证两处输出都为
[never]后，**必须重启 Redis 进程**（fork重写时才真正避开 THP 影响） - 普通用户执行报
Permission denied；容器若挂载/sys为只读，该操作直接失败
永久禁用（生产环境唯一可靠方式）
/etc/rc.local 在 systemd 系统中不可靠，CentOS 7+/RHEL 8+/Ubuntu 20.04+ 必须用 systemd service。
- 创建服务文件：
/etc/systemd/system/disable-thp.service - 内容关键点：
DefaultDependencies=no和Before=sysinit.target，确保它在几乎所有服务（包括 Redis）启动前运行 -
ExecStart必须同时写两个 echo 命令，缺一不可：echo never > /sys/kernel/mm/transparent_hugepage/enabled && echo never > /sys/kernel/mm/transparent_hugepage/defrag - 启用服务：
systemctl daemon-reload && systemctl enable disable-thp.service && systemctl start disable-thp.service
验证 THP 是否真正退出 Redis 进程
光看 /sys 下的状态还不够——Redis 主进程的内存页可能已被 THP 悄悄“污染”过。
- 先用
ps aux | grep redis-server拿到主进程 PID - 再查它的
/proc/<pid>/smaps</pid>：grep -i "mmupage\|mmupf" /proc/<pid>/smaps | head -10</pid> - 正常应全是
MMUPageSize: 4 kB；若出现大量2048 kB，说明 THP 仍在生效，常见于其他服务（如 MySQL、Java 应用）启动脚本里偷偷启用了它
THP 不是“开了慢一点”，而是让 fork 耗时放大 512 倍，导致 bgsave 卡几百毫秒、incr 进 slowlog、集群槽位迁移超时——这些现象背后大概率是同一个开关没拧紧。
