多数数据库推荐禁用thp，因其后台扫描、延迟分配、内存碎片及监控失真等问题会损害oltp低延迟性能；仅在大规模顺序扫描等特定olap场景下可考虑madvise模式启用。
Linux 透明大页（THP）对数据库性能的影响取决于工作负载特性，多数 OLTP 场景下建议禁用 THP，而部分 OLAP 或内存密集型批量任务可能从中受益，但需实测验证。
为什么多数数据库（如 MySQL、PostgreSQL、MongoDB）推荐禁用 THP
THP 在后台自动将 4KB 小页合并为 2MB 大页，虽降低 TLB miss，但其“透明”机制带来不可控开销：
- 周期性内存扫描与合并：khugepaged 进程持续扫描匿名内存页，触发锁竞争和 CPU 抖动，干扰数据库的低延迟响应
- 延迟分配与写时复制问题：THP 的 deferred 分配模式在 fork()（如 PostgreSQL 的 backend process 创建）或内存压力下易引发突发延迟
- 内存碎片与分配失败：2MB 连续物理内存难满足，尤其在长期运行、内存分配不均的数据库进程中，导致 fallback 到小页并伴随警告（dmesg 中可见 “khugepaged: failed to allocate hugepage”）
- 监控与诊断失真：/proc/meminfo 中 AnonHugePages 显示非零值，但实际是否被有效使用难以判断；perf 或 pstack 分析时也易掩盖真实内存行为
如何检查和禁用 THP
确认当前状态：
cat /sys/kernel/mm/transparent_hugepage/enabled
输出类似 [always] madvise never 表示启用中（方括号内为当前模式）
临时禁用（重启失效）：
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
永久禁用（推荐方式）：
- 在 GRUB 启动参数中添加 transparent_hugepage=never（如编辑 /etc/default/grub，更新 GRUB_CMDLINE_LINUX，再运行 update-grub && reboot）
- 或通过 systemd service 在启动时写入（适用于无法修改 grub 的容器/云环境）
例外情况：什么场景可考虑保留 THP？
并非所有数据库都一概禁用，需结合访问模式判断：
- 大规模顺序扫描型负载（如 ClickHouse、某些 Spark on YARN 场景）：连续大内存访问 + 高吞吐，TLB 效率提升可能压倒 khugepaged 开销
- 启用 jemalloc/tcmalloc 且关闭了 mmap 的应用：内存分配器自行管理大块内存，THP fallback 概率降低
- madvise 模式 + 应用显式提示：若数据库自身调用 madvise(MADV_HUGEPAGE)（如较新版本 Redis），则仅对指定区域启用，风险可控
注意：即使考虑启用，也应设为 madvise 而非 always，避免全局影响。
验证效果与监控建议
禁用后观察关键指标变化：
- 数据库 P99 延迟是否下降（尤其高并发短事务）
- 系统级：vmstat 1 查看 cs（context switch）、us/sy 波动；pidstat -r -p $(pgrep mysqld) 1 观察 %mem 和 majflt（主缺页）频次
- 内核日志：dmesg -T | grep -i huge 确认无 fallback 或合并失败告警
- 对比启用/禁用前后相同 SQL 的执行计划稳定性（THP 导致的延迟毛刺可能干扰查询优化器统计信息更新）
