数据库场景应禁用透明大页（THP），因其引发内存延迟升高、周期性卡顿等问题；需确认THP是否为always模式，检查khugepaged日志线索，临时及永久关闭并验证AnonHugePages为0及延迟改善。
排查回收日志中因透明大页（THP）配置冲突引发的长卡顿，核心在于确认 THP 是否处于 always 模式，并验证其后台合并线程 khugepaged 是否在数据库或高频率内存分配场景下造成锁竞争与延迟抖动。
看日志里有没有 khugepaged 或 defrag 相关线索
长卡顿发生时段的系统日志（/var/log/messages 或 dmesg -T）中，留意以下关键词：
-
khugepaged: defrag—— 表示内核正在主动合并小页为大页 -
mm: page allocation failure或order-数值偏高（如order-9）—— 可能因 THP 合并失败触发重试或阻塞 -
thp: collapse、thp: split—— 显示大页频繁拆合，是抖动的直接信号
查当前 THP 状态和进程级影响
执行以下命令快速定位问题根源：
-
cat /sys/kernel/mm/transparent_hugepage/enabled—— 若显示[always]，即存在高风险 -
cat /sys/kernel/mm/transparent_hugepage/defrag—— 若为[always]，说明后台持续尝试合并，加剧干扰 -
grep AnonHugePages /proc/$(pgrep -f "mysqld|postgres|redis-server")/smaps | awk '{sum += $2} END {print sum " KB"}'—— 非零值说明该进程已被 THP 影响
验证卡顿是否由 THP 引起
临时禁用后对比观察是最直接的方法：
- 执行：
echo never > /sys/kernel/mm/transparent_hugepage/enabled和echo never > /sys/kernel/mm/transparent_hugepage/defrag - 重启数据库服务（确保新内存分配不走 THP）
- 用
perf stat -e major-faults,minor-faults -p $(pgrep -f "mysqld") -I 1000监控每秒缺页数，禁用前后若 major-faults 显著下降、延迟毛刺消失，即可确认 THP 是元凶
生产环境必须固化关闭
临时关闭不能解决重启后复发问题，需永久生效：
- 编辑
/etc/default/grub，在GRUB_CMDLINE_LINUX行末添加transparent_hugepage=never - 执行
update-grub && reboot（Ubuntu/Debian）或grub2-mkconfig -o /boot/grub2/grub.cfg && reboot（CentOS/RHEL/银河麒麟） - 重启后再次运行
cat /sys/kernel/mm/transparent_hugepage/enabled，确认输出为always madvise [never]
