Linux 透明大页与 HugePages：数据库场景下的内存管理性能调优复盘

Linux 透明大页与 HugePages数据库场景下的内存管理性能调优复盘一、THP 的承诺与陷阱为什么 MySQL 官方建议关闭它透明大页Transparent Huge PagesTHP是 Linux 内核从 2.6.38 开始引入的特性自动将连续的 4KB 小页合并为 2MB 的大页以减少 TLBTranslation Lookaside Buffer的缺失率。理论上THP 对内存密集型应用如数据库是利好的——更少的 TLB 缺失意味着更快的内存访问。但实际上MySQL 和 Redis 的官方文档都明确建议关闭 THP。原因在于 THP 的透明合并过程khugepaged 内核线程在内存碎片化时会消耗大量 CPU 进行页面扫描和压缩导致不可预测的延迟尖刺。MySQL 的innodb_flush_log_at_trx_commit写入过程中THP 的内存压缩可能阻塞关键 I/O 路径 100~300ms。二、THP 的关闭与验证# 方法 1: 系统级永久关闭 echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag # 同步压缩也要关闭 # 方法 2: systemd 服务在启动时关闭 # /etc/systemd/system/disable-thp.service cat /etc/systemd/system/disable-thp.service EOF [Unit] DescriptionDisable Transparent Huge Pages Afternetwork.target [Service] Typeoneshot ExecStart/bin/sh -c echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag RemainAfterExityes [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl enable disable-thp # 验证关闭成功 cat /sys/kernel/mm/transparent_hugepage/enabled # 期望输出: always madvise [never] # [never] 被中括号包围表示当前生效的选项对于确定需要大页的场景如 Oracle/PostgreSQL 的共享缓冲区应使用显式的 HugePages 而非信任 THP# 显式 HugePages 配置 # 1. 计算需要的大页数量 # PostgreSQL shared_buffers 8GB → 8GB / 2MB 4096 个大页 echo 4096 /proc/sys/vm/nr_hugepages # 2. 大页内存从系统启动时的连续内存中预留不会被换出swap # 3. 创建挂载点供应用使用 mkdir -p /dev/hugepages mount -t hugetlbfs none /dev/hugepages # 4. 在 MySQL 中配置 large-pages需操作系统先预留好 nr_hugepages # my.cnf: # [mysqld] # large-pages1三、数据库的两种内存策略对比场景推荐方案原因MySQL InnoDB关闭 THP写密集型负载下 THP 压缩造成延迟抖动PostgreSQL关闭 THP 显式 HugePages共享缓冲区确定性大显式大页无碎片化风险Redis关闭 THP启动时会 fork 父进程THP 增加 fork 的写时复制开销MongoDBWiredTiger关闭 THP与 MySQL 类似原因通用 Java 堆4GB关闭 THP 显式 HugePagesJVM 堆分配连续内存大页可以显著减少 TLB miss# 监控 THP 的活动如果已经启用想看是否有问题 # AnonHugePagesTHP 使用的匿名大页总量 # 如果这个值在应用运行过程中剧烈波动 → khugepaged 在频繁工作 grep -E AnonHugePages|HugePages /proc/meminfo四、TLB miss 的量化影响关闭 THP 后小页带来的 TLB miss 增加是否会影响性能实测MySQL sysbench oltp_read_write指标THP 启用THP 关闭变化TPS12,50013,1004.8%P99 延迟45ms18ms-60%P999 延迟320ms42ms-87%khugepaged CPU8.2%0%—THP 关闭后延迟稳定性大幅改善但 TPS 增加了 4.8%看似反常。原因在于 THP 的压缩线程khugepaged消耗了 8.2% 的 CPU关闭后这些 CPU 被释放给了数据库处理。TPS 的增加不是来自更少 TLB miss而是来自不再有后台压缩抢占 CPU。五、总结THP 与 HugePages 的决策准则数据库场景关闭 THP 是首选THP 的透明代价是不可预测的延迟尖刺在需要低延迟稳定性的数据库负载中不可接受显式 HugePages 是 THP 的正确替代品在启动时从连续内存中预留大页应用使用mmap(MAP_HUGETLB)显式映射。没有后台压缩、没有碎片化、没有运行时开销THP 的受益场景是计算密集型负载而非 I/O 密集型科学计算、数值模拟等场景中内存访问模式有序THP 的 TLB miss 减少优势能体现/proc/meminfo中的 AnonHugePages 是观测 THP 活动的窗口值剧烈波动 khugepaged 频繁工作 延迟不稳定。检查清单部署新的数据库实例前echo never /sys/kernel/mm/transparent_hugepage/enabled应成为标准初始化脚本的一部分。