前阵子线上一个Go服务突然被值班群喊起来说内存在飙。我看了眼监控RSS一路爬到了8个多G可这个服务平时堆内存也就两个G出头。第一反应是“肯定泄漏了”于是很快打了pprof heap profile结果heap inuse 2.1G完全正常。这就很诡异了对象没有泄漏RSS却虚高了两三倍。后来一层层往下查从Go runtime查到内核最终定位到真凶是THPTransparent Huge Pages透明大页。这篇文章就把这次排查THP导致Go内存异常的全过程、底层原理以及一些可以直接照抄的止血和预防方案写出来。如果你是正在被“Go服务RSS虚高”“GC延迟抖动”“CPU随机尖峰”这类问题折磨的运维、SRE或Go开发这篇内容应该能帮你少熬几个通宵。1. THP是什么为什么它会跟Go程序“打架”1.1 先看现场一次典型的内存异常长什么样先描述一下当时的具体表现方便大家对号入座。那个服务跑在CentOS 7.9上内核3.10容器部署Java和Go混部的一批机器。Go服务的指标大概是这个样子RSS稳定在8.2G左右而进程实际使用的堆内存只有2.1G。VIRT高达14G因为Go运行时本来就会为自己保留大块虚拟地址空间。GC平均暂停时间2ms左右但每隔一段时间会突然跳到40-50ms。CPU平均占用不算高但监控曲线上能看到毫无规律的尖峰。用top看进程状态大部分时间是S睡眠偶尔有R状态的瞬时飙升。如果只看前面几条确实非常像内存泄漏。但pprof打出来的heap profile明明白白告诉你堆上对象总量不大也没有持续增长。这时候如果继续往业务代码里找大概率是浪费时间。这类问题的共同特征是“程序侧看到的堆内存”和“系统侧看到的RSS”之间出现了巨大落差而且GC之后RSS也降不下来。经验里遇到这种组合优先怀疑对象就两个方向要么是Go runtime归还内存给内核的机制MADV_FREE相关要么是内核主动把进程内存搞成了大页也就是本篇的主角THP。1.2 THP机制拆解内核如何“好心办坏事”要理解THP先得知道一点内存分页的基础。操作系统的物理内存是按“页”来管理的默认页大小通常是4KB。进程访问内存时CPU通过页表把虚拟地址翻译成物理地址。页表条目越多翻译开销越大所以CPU里还有一个专门的缓存叫TLB用来缓存最近用过的页表项。TLB容量很有限如果访问的内存区域很大、页又很小TLB miss就会频繁发生程序性能就往下掉。大页Huge Pages的思路很简单把页大小从4KB提升到2MB甚至1GB。页数量变少了页表项也就少了TLB命中率自然更高。传统上使用大页需要程序自己调用mmap或者hugetlbfs等机制来申请比较麻烦。THP则把这个过程“透明化”了内核在后台自动把进程地址空间里连续的4KB小页合并成2MB大页不需要程序做任何事。内核里干这个活的叫khugepaged是一个后台内核线程。它会周期性扫描系统中可合并的内存区域发现合适的就尝试合并。除了后台合并THP在分配内存时也可能直接尝试分配大页。这里可以打个生活化的比方你搬家时把所有小盒子统一装进大纸箱仓库看起来整齐了搬运效率也高了。但问题是如果某天你只想从大纸箱里拿一个小零件也得先把整个大纸箱拆开翻找成本反而变高了。THP就是那个总爱打包的仓库管理员对你的杂物间进行“自动优化”但完全没考虑你后续频繁存取小件物品的习惯。目前Linux内核里THP可以通过enabled参数设置三种模式模式含义对Go服务的影响always内核尽量使用大页后台自动合并影响最明显容易出现RSS虚高和延迟尖峰madvise只有进程主动调用madvise(MADV_HUGEPAGE)才使用大页Go runtime一般不主动申请基本无影响never完全关闭THP最保守效果最直接和enabled配套的还有一个defrag参数它控制内存碎片整理compaction的策略。常见的值有always、defer、defermadvise、madvise、never。如果defrag是always内核在分配大页遇到内存碎片时会同步地把物理内存整理出连续区域这个整理过程可能让线程等上几十甚至上百毫秒。在延迟敏感的服务上这就是一次明显的毛刺。1.3 Go运行时为什么偏偏容易吃亏很多人会问THP存在这么多年了为什么偏偏Go服务受影响比较明显这跟Go运行时管理内存的方式有很大关系。Go的堆内存是通过mmap向操作系统申请的大块虚拟地址空间申请之后基本不会归还虚拟地址。GC在回收内存后想释放一部分物理页时并不会直接munmap而是调用madvise告诉内核“这块内存没用了你可以回收”。也就是说这些刚被GC标记为可回收的物理页虽然业务上已经“没用了”但页表项还在进程地址空间里。问题就在这里。在always模式下khugepaged在后台扫描时看到的是大量连续的、映射在进程地址空间里的匿名页它可不管这些页是“活跃数据”还是“刚被GC遗弃的垃圾”只要符合条件就尝试合并成2MB大页。一旦合并成功后面GC想把这些页面按4KB粒度还给操作系统就不是那么容易了。内核得先花成本把大页拆分回小页再逐页回收。具体到表现上主要有三个冲突点内存回收粒度变大4KB单位变成了2MB单位一堆只有零星几个活跃对象的物理页被大页“绑架”进程的RSS自然居高不下。GC路径上多了拆页开销Go的GC在释放内存时触发madvise如果目标页面正好是大页内核处理的时间会明显变长这就是GC暂停时间突然飙高的来源之一。分配路径上的同步压缩如果内核为了分配大页去做direct compaction线程会被卡住延迟尖峰就是这么来的。一个C/C常驻服务如果内存布局稳定、分配模式固定THP的负面效应可能还不明显但Go服务是高频率分配、高频率GC、大块堆内存长期不释放虚拟地址跟THP的“自动打包”碰到一起几乎是把THP的缺点放到了最大。2. 如何确认内存异常真的与THP有关2.1 先别急着改代码三步锁定问题归属排查内存问题最忌讳的就是一上来就怀疑自己的代码然后对着pprof反复消耗。我的习惯是先分三步缩小范围每一层都有实锤再往下走。第一步排除Go自身的内存泄漏。用pprof抓heap profilecurl http://localhost:6060/debug/pprof/heap?seconds30 -o heap.out go tool pprof -top heap.out重点关注heap_inuse、heap_objects和goroutine数量。如果堆对象总量稳定goroutine数量没有持续增长基本可以排除业务代码层面的泄漏和goroutine泄漏。第二步对比RSS和堆实际占用。在服务上打一个runtime.MemStats或者直接用pprof看到的数据同时看一下top里的RES。我当时看到的就是RES 8.2Gheap_inuse 2.1G二者差了6个G。如果此时GC之后RSS依然没有明显回落那问题几乎可以肯定不在Go的堆对象上而在内核怎么看待这些内存。第三步检查进程的大页映射情况。也就是下面要说的smaps。2.2 用smaps实锤怎么看大页映射Linux内核在/proc/pid/smaps里记录了进程每一段内存映射的详细信息其中有一个字段叫AnonHugePages专门统计这段映射里匿名大页占用的内存。我们可以直接统计整进程的大页总量grep -i anonhugepages /proc/pid/smaps | awk {sum$2} END {printf %.2f MB\n, sum/1024}当时执行完的结果让我印象很深4.6G左右。也就是说进程RSS里有超过一半的物理内存被内核合并成了2MB大页。再回头看RSS 8.2G、heap_inuse 2.1G的数据逻辑就通了Go的堆空间长期映射在进程里GC后那些“空闲”的匿名页被THP打包固定住既没有真正释放给内核又被计入RSS看起来就像平白无故多占了好几个G。如果只是想快速查看单个进程也可以直接看status文件grep -i anon /proc/pid/status输出里能看到AnonHugePages这一行的值。这里补充一个容易踩的坑不要在容器里只看container_memory_working_set_bytes或者RSS就下结论。RSS会把所有映射到进程地址空间的物理页都算进去不管它是共享的还是私有的而PSSProportional Set Size会按比例分摊共享页更能反映真实内存占用。在排查内存虚高问题时RSS和PSS要分开看别混为一谈。2.3 顺手检查系统THP配置确认进程大页映射之后还要检查系统当前的THP配置确认它确实是“开着且激进”的状态。cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag第一条命令输出可能是[always] madvise never方括号里标注的是当前生效模式。如果方括号在always上基本就实锤了。第二条命令看碎片整理策略。如果输出是[always] defer defermadvise madvise never说明内核在尝试分配大页时会执行同步内存压缩这对低延迟服务来说是比较危险的配置。很多云厂商的基础镜像、旧版CentOS、部分容器宿主机的默认配置恰好就是always。不少人以为THP是默认关闭的实际上在不少发行版里它反而是默认开启的。这就是为什么这类问题总是一阵一阵地冒出来换了一批机器、换了一个集群表现还不一样。3. 解决方案与实施步骤3.1 方案一生产环境最稳妥的做法直接关掉THP对于绝大多数Go服务来说THP带来的收益很有限负面问题却很突出所以最推荐的方案就是直接在宿主机层面关闭THP。临时关闭可以执行echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag但这种方式重启后就会失效适合用来快速验证“关掉THP到底能不能解决问题”。如果验证有效需要永久生效。最常见的方式是修改内核启动参数编辑/etc/default/grub在GRUB_CMDLINE_LINUX里加上一行transparent_hugepagenever然后重新生成grub配置并重启grub2-mkconfig -o /boot/grub2/grub.cfg reboot不同发行版路径可能不同Ubuntu一般是grub-mkconfig -o /boot/grub/grub.cfg操作前先确认自己的系统。不方便重启机器时也可以用systemd服务在启动阶段设置[Unit] DescriptionDisable Transparent Huge Pages (THP) Beforesysinit.target [Service] Typeoneshot ExecStart/bin/sh -c echo never /sys/kernel/mm/transparent_hugepage/enabled; echo never /sys/kernel/mm/transparent_hugepage/defrag [Install] WantedBysysinit.target保存到/etc/systemd/system/disable-thp.service然后执行systemctl daemon-reload systemctl enable --now disable-thp.service这里有一个非常重要的提醒关闭THP并不会让已经合并的大页立刻消失。要么重启目标Go服务让进程的页表重新构建要么等系统内存压力变大后由内核逐步回收。最直接有效的验证流程是修改内核参数 - 重启宿主机或目标服务 - 再观察RSS。3.2 方案二不想全局关闭时的折中用madvise模式有些团队因为数据库、大数据组件等确实能吃到THP红利不希望全局关掉。这种情况下可以把THP从always降级为madviseecho madvise /sys/kernel/mm/transparent_hugepage/enabled echo madvise /sys/kernel/mm/transparent_hugepage/defragmadvise模式的含义是只有进程主动调用madvise(MADV_HUGEPAGE)时内核才对这个区域使用大页。Go runtime目前并没有主动为堆内存申请大页所以在这种模式下Go服务基本不会被THP影响。这样做既保留了给JVM、数据库等明确使用大页的场景又避免了内核在后台“偷摸”合并Go服务的堆内存。如果你所在的团队有平台规范建议把这一条写进基础镜像的初始化脚本里。3.3 方案三程序侧兜底宿主机管不到也要自救有些场景下你根本改不了宿主机内核参数比如你只是容器里的一个租户或者云托管服务。这时候就要在Go程序侧做一些兜底。先说一个最直接的调优开关GODEBUGmadvdontneed1。在Go 1.16之后的版本runtime在向内核归还内存时Linux上默认会使用MADV_FREE这是一种惰性回收机制内核收到指令后只是标记页面“可回收”但物理页面并没有立刻解除映射所以RSS不会马上下降。加上THP的合并RSS虚高的现象就会更明显。设置GODEBUGmadvdontneed1可以让runtime改用MADV_DONTNEED更快解除映射并归还物理页但后续再次访问这些内存时需要重新缺页加载可能会带来额外的CPU开销。建议先在压测环境验证对性能的影响再决定是否上线。然后是堆大小控制。通过环境变量或代码设置GOMEMLIMIT可以给Go运行时一个“软上限”让它更积极地控制堆的增长export GOMEMLIMIT4GiB配合GOGC调节GC频率可以避免堆空间膨胀到让THP有大量可合并页面的程度。不过在THP问题面前这只是缓解手段不是根治手段。代码侧也可以做一些配合。比如减少高频的大块内存分配尽量复用对象和缓冲区降低页面的频繁映射与释放。但说实话在系统配置修好之前代码侧优化都是治标不治本优先级不用放太高。3.4 验证与效果对比一次真实的指标变化关闭THP、重启服务之后我记录了同一时段、同一业务流量下的指标变化。指标关闭前关闭并重启后RSS峰值8.2G3.0G左右RSS与heap差值约6G约1G以内GC平均暂停2ms1.8msGC P99暂停48ms3.1msCPU尖峰频繁出现基本消失RSS从8.2G掉到3G左右虽然和heap_inuse的2.1G还有一点差距但已经是正常范围了那部分差异主要是Go runtime自身的管理结构和MADV_FREE导致的延迟归还。真正吓人的大页占用直接归零。GC P99从48ms降到3.1ms这是最直观的收益。之前那些随机出现的延迟尖峰很大一部分就是内核在拆分大页、回收内存的过程中造成的。4. 常见问题与排查技巧实录4.1 这些“疑似THP”的坑其实不是THP把THP排查清楚之后并不意味着所有内存异常都归它管。实际排查中遇到过不少容易跟THP混淆的情况这里列一个速查表方便大家按图索骥。现象常见根因排查方向RSS高heap正常GC后RSS不降THP合并大页、MADV_FREE惰性归还查smaps的AnonHugePages确认enabled模式RSS缓慢增长heap_objects也在涨协程泄漏、对象引用未释放pprof goroutine、pprof heap对比GC暂停偶发飙升THP拆页、系统内存压力、大对象分配结合THP配置和内存监控看heap正常但PSS也很高cgo或C库分配的内存pprof看不到pmap、perf、原生内存分析工具重启后内存正常运行几天又飙THP合并积累、MADV_FREE积累关闭THP后观察是否复发特别提一下cgo的情况。如果你在Go代码里调用了C库C库自己分配的内存在pprof heap里是看不到的但它会真实占用进程RSS。这个问题跟THP无关但表象极像“内存泄漏”。排查时如果发现Go堆很正常但RSS一直在涨建议用pmap -x pid看看有没有哪段内存映射增长明显尤其是带/anon的匿名映射。4.2 一键检查脚本直接拿走为了以后排查方便我写了一个小脚本专门用来快速检查一台机器和一个进程跟THP相关的情况#!/bin/bash # usage: ./check_thp.sh [pid] echo THP enabled cat /sys/kernel/mm/transparent_hugepage/enabled echo echo THP defrag cat /sys/kernel/mm/transparent_hugepage/defrag echo echo khugepaged process pgrep -a khugepaged || echo khugepaged not running echo if [ -n $1 ]; then pid$1 echo PID $pid status grep -i anon /proc/$pid/status || echo no AnonHugePages field echo echo PID $pid total AnonHugePages from smaps grep -i anonhugepages /proc/$pid/smaps | awk {sum$2} END {printf %.2f MB\n, sum/1024} fi实际使用的时候直接./check_thp.sh pid如果系统层面是always进程层面又有大几GB的AnonHugePages那基本可以判定问题根源了。4.3 长期运营Go服务的一些配置习惯经历过这次排查之后我把自己经手的Go服务部署规范里加了几条硬性要求这里也分享出来新机器初始化时强制检查THP的enabled和defrag必须是never或madvise不做例外。容器集群的节点模板里加一条systemd服务确保重启后配置不掉。监控上不只盯RSS还要盯GC暂停耗时、khugepaged线程的CPU占用、内核的compaction计数。每次大版本升级内核或更换云厂商镜像后重新执行一遍THP检查。还有一个小技巧上线新服务或者给老服务做压测前可以在低峰期先把THP临时关闭对比一下GC和延迟指标。如果前后差异不明显再决定要不要永久保留配置。这样能避免盲目“一刀切”关掉THP后某个依赖大页性能的组件突然出现性能回退。最后分享一个我个人的运维习惯凡是跑Go服务的机器拿到手第一步就是确认THP和swappiness这两个内核参数不管业务方有没有报内存问题都先查一遍。这次排查的经验也证明很多你以为是代码泄漏的问题根子其实在内核。排查顺序上先看内核层、再看runtime、最后才是业务代码往往能少走很多弯路。