搬运并适配自国外社区真实案例。原文出处见文末。TL;DR症状生产数据库突然出现周期性延迟尖刺P99 从 2ms 跳到 2000msCPU 无异常磁盘 IO 正常内存余量充足。根因内核 Transparent Huge PagesTHP默认defragalways模式在分配大页时触发同步内存压缩compact_memorySTWStop-The-World长达数百毫秒。解决echo never /sys/kernel/mm/transparent_hugepage/defrag改异步压缩khugepaged或直接关闭。权威背书Red Hat、MongoDB、PostgreSQL 官方文档均建议数据库场景关闭 THP。现象$topPID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND9876 mysql 20 0 16.2g 8.1g 8232 S 5.0 5.1 24:30.12 mysqld$free-htotal used free shared buff/cache availableMem: 157Gi 96Gi 8.0Gi 450Mi 53Gi 58GiSwap: 2.0Gi 0.0Gi 2.0Gi$vmstat1procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st3 0 0 8264832 678912 56053760 0 0 1234 5678 28901 4503 8 2 88 2 08 1 0 8251392 678912 56054784 0 0 512 0 → 突然大量线程阻塞在 D 状态$cat/proc/vmstat|grep-Ecompact|thp|kswapdcompact_migrate_scanned 283471923compact_free_scanned 891234567compact_isolated 45678234thp_fault_alloc 123456thp_fault_fallback 9876543 ← 分配大页失败次数极高thp_collapse_alloc 234567环境CentOS 7 / Linux 4.18.0 | MySQL 8.0 InnoDB | 128GB 内存 | 运行 6 个月正常近期延迟尖刺从每月 1 次增加到每天 3 次。排查过程第一回合常规诊断 → 无功而返$iostat-x1#磁盘await2ms没有问题$perftop-p$(pgrepmysqld)#热点函数正常ha_innobase::index_read、btr_search_guess_on_hash#没有异常锁竞争为什么常规指标失灵THP 压缩在khugepaged内核线程中执行不消耗进程 CPU 时间、不产生磁盘 IO、不改变free -h数值。它只做一件事把分散的 4KB 物理页搬到一个连续区域。这个过程不改变进程地址空间但对被移动页面的任何访问都会触发硬件 page fault —— 等待时间远超正常内存访问。第二回合抓到关键信号$cat/proc/vmstat|grepcompact_compact_migrate_scanned 283471923 # 已扫描的迁移页面compact_free_scanned 891234567 # 已扫描的空闲页面compact_isolated 45678234 # 已隔离的页面compact_stall 1234 ← 关键触发同步压缩停滞compact_fail 567 # 压缩失败次数$cat/proc/vmstat|grepthpthp_fault_alloc 123456 # fault 时成功分配大页thp_fault_fallback 9876543 # fallback 到 4KB ← 极高thp_collapse_alloc 234567 # khugepaged 合并成功thp_split_page 45678 # 大页被拆分compact_stall1234意味着应用线程在alloc_pages()时被强制等待内存压缩完成——这是同步阻塞时长取决于物理内存碎片化程度。第三回合定位根因参数$cat/sys/kernel/mm/transparent_hugepage/enabled[always] madvise never$cat/sys/kernel/mm/transparent_hugepage/defrag[always] defer defermadvise madvise never两个参数都设成了always -enabledalways→ 所有进程默认尝试用大页 -defragalways→ 如果大页分配失败同步等待内存压缩——应用线程卡住等内核把碎片整理好数据库运行 6 个月后物理内存碎片化严重大页分配失败概率飙升 →compact_stall从 0 增长到 1234 → 每次 STW 100-2000ms。第四回合确认效果#方案1defrag改异步推荐$echonever/sys/kernel/mm/transparent_hugepage/defrag$echonever/sys/kernel/mm/transparent_hugepage/enabled#验证$cat/proc/vmstat|grepcompact_stallcompact_stall 1234 # 不再增长#应用延迟恢复$# P99 恢复至 10ms根因内核代码级解析THP 的核心在两个文件中mm/huge_memory.c— fault-time 分配进程缺页中断时内核尝试分配 2MB 大页mm/khugepaged.c— 后台合并khugepaged内核线程扫描把连续 4KB 页合并成大页当defragalways时fault-time 分配失败后的逻辑简化// mm/page_alloc.c — __alloc_pages_slowpath()staticstructpage*__alloc_pages_slowpath(gfp_tgfp_mask,...){// ... reclaim 尝试后仍失败// defragalways → 同步压缩if(gfp_mask__GFP_DIRECT_RECLAIM){// try_to_compact_pages() 会迁移页面耗时取决于碎片程度page__alloc_pages_direct_compact(gfp_mask,order,...);// 这个过程可能耗时数百毫秒}// 失败 → 返回 4KB 页面fallbackreturnfallback_to_4k_pages();}为什么数据库场景特别严重 - 数据库的内存访问模式偏向随机读写页面分散THP 的连续虚拟地址 → 连续物理地址优势不明显 - InnoDB 的innodb_flush_methodO_DIRECT绕过 page cacheTHP 对数据库页面的加速效果几乎为零 - 频繁malloc/free导致物理内存碎片化大页分配失败率随时间线性增长为什么 Redis 也受影响 - Redis fork 子进程做 RDB/AOF rewrite 时Copy-on-WriteCOW会因 THP 放大一个 2MB 大页哪怕只改 1 byte也要完整复制 2MB解决方案按推荐度方案 1彻底关闭 THP数据库场景首选# 立即生效echonever/sys/kernel/mm/transparent_hugepage/enabledechonever/sys/kernel/mm/transparent_hugepage/defrag# 持久化cat/etc/rc.local EOFecho never /sys/kernel/mm/transparent_hugepage/enabledecho never /sys/kernel/mm/transparent_hugepage/defragEOF# 或 grub 内核参数# /etc/default/grub:# GRUB_CMDLINE_LINUXtransparent_hugepagenever# $ grub2-mkconfig -o /boot/grub2/grub.cfg方案 2用defer模式折中echodefer/sys/kernel/mm/transparent_hugepage/defragdefer模式fault 时不触发同步压缩交给khugepaged后台异步处理。应用线程不卡但大页利用率可能略低。方案 3per-process 精细化控制JH/Java 场景# 只给 Java heap 开 THPmadvise 模式echomadvise/sys/kernel/mm/transparent_hugepage/enabled# Java 启动参数# -XX:UseTransparentHugePages 或 -XX:UseLargePages如何自检你是否中招# 一行命令检查是否有同步压缩停滞awk/^compact_stall/ { stalls$2 }/^thp_fault_alloc/ { alloc$2 }/^thp_fault_fallback/ { fallback$2 }END {printf compact_stall%d, alloc%d, fallback%d\n, stalls, alloc, fallback;if (stalls 0) print ⚠️ 检测到同步压缩停滞建议关闭 THP 或改 defragdefer;if (fallback alloc * 10) print ⚠️ 大页分配成功率 10%物理内存碎片化严重}/proc/vmstat持续监控脚本/etc/cron.d/thp-monitor*/5****rootawk/compact_stall/{s$2}/compact_fail/{f$2}END{if(s100||f50)system(logger -t thp-monitor WARNING compact_stalls compact_failf)}/proc/vmstat启示默认配置不是为你优化的——Linux 内核 THP 默认always是为通用负载Web 服务、文件服务器设计的不是为数据库。数据库场景 90% 的情况该关掉。内存余量充足 ≠ 没有内存问题——THP 的延迟尖刺在free -h、vmstat、iostat上都不可见。唯一能抓到的信号是compact_stall字段。不要只用enabled一定要管defrag——很多运维只关了enabled但defrag还是always以为问题解决了。两个参数独立生效。碎片化随时间加重——今天没延迟不代表明天没有。物理内存碎片化是不可逆的累积过程compact_stall只增不减除非 reboot。透明不透明——THP 的名字承诺对应用透明但延迟尖刺就是透明度破产的证明。真正透明的性能提升不该有代价。原始出处 - kernel.org: Transparent Hugepage Support — 官方文档defrag 五种模式详解 - kernel-internals.org: THP — 内核数据结构、khugepaged 扫描机制、/proc/vmstat字段解释 - Red Hat Performance Tuning Guide — RHEL 官方建议数据库场景禁用 THP - YugabyteDB TA-26440 — THP 导致内存使用异常增长和 RSS 膨胀本文首发于 CSDN 专栏《运维漏洞指南》。每篇都是排查回合制实录从现象到内核代码给可执行命令而非堆概念。