简介本资源为一份PDF格式的Linux HugePages配置指南面向需要优化大内存应用性能的系统管理员、DBA及运维工程师尤其适合为Oracle数据库等场景快速启用大页内存。内容从memlock限制、vm.nr_hugepages参数设置到hugepages_settings.sh脚本的使用均有清晰阐述并给出sysctl与重启生效的完整流程还特别整理了ASM/AMM兼容性、SGA与pga_aggregate_target计算等关键注意事项帮助读者规避常见误区。资源包共1个PDF文件大小约53KB便携易用可在本地或服务器上随时查阅。目前已有1702人学习浏览适合具备一定Linux基础、希望快速掌握HugePages配置实操的读者作为简明参考手册。1. HugePages让数据库和中间件性能翻倍大多数Linux服务器其实没吃透这个参数我给一台跑着Oracle的服务器做性能排查时top 里 CPU 的 sy 列长期占着 30% 以上数据库业务量却不大。查了一圈最后定位到问题不在 SQL而是内核的页表开销把 CPU 烧掉了。这种情况在 Linux 服务器上太常见了内存越配越大内核默认的 4KB 页帧让页表项膨胀到千万级TLB 缓存根本装不下访问内存时 CPU 只能不断去查页表。HugePages大页就是把这个粒度从 4KB 放大到 2MB 甚至 1GB让页表项数量直接砍掉两个数量级TLB 命中率上去了CPU 自然就闲下来。这篇文章要讲的是怎么在 Linux 系统下快速把 HugePages 配置起来。我会从原理讲到落地命令再到参数调整和验证方法最后把我在生产环境里踩过的坑一条条列给你。适合正在维护数据库、中间件、JVM 大堆服务或者做嵌入式 Linux 调优的运维和开发。你照着步骤走半小时内能把一个节点的大页池建起来并验证到位。2. 为什么要快速配置HugePages页表开销与TLB命中率背后的账2.1 页表膨胀与TLB miss一个4KB页帧的真实开销Linux 内核默认把物理内存切成 4KB 的页帧来管理。一个进程想访问虚拟内存CPU 得通过多级页表把虚拟地址翻译成物理地址这中间每一级查表都在消耗时间。最要命的是内存一多页表本身就会长得非常夸张一台 128GB 内存的机器如果全用 4KB 页光页表项就要 3200 万个每张页表项就算只占 64 字节也要吃掉将近 2GB 的内存来放页表。更直接的代价在 TLBTranslation Lookaside Buffer上。TLB 是 CPU 内部缓存最近用过的虚拟地址到物理地址映射的硬件大小通常只有几百到几千条。进程每访问一个没有命中 TLB 的页都要走一遍完整的多级页表查表流程这种 miss 在 CPU 的 perf 统计里会表现为很高的 cycle 开销在 top 里就是 sy 列居高不下。数据库这类大内存进程工作集会高频访问分布在大范围地址上的数据4KB 页会让 TLB 频繁失效CPU 大量时间花在内核态的地址转换上业务线程反而抢不到执行资源。HugePages 把页帧放大到 2MB 或 1GB页表项数量直接缩减为原来的 1/512 或 1/262144。对 Oracle SGA、PostgreSQL shared buffers、JVM 堆这类动辄几 GB 到几百 GB 的常驻内存使用大页后 TLB miss 率能成数量级下降。我接触的项目里配置完 HugePages 的数据库服务器CPU sy 占比普遍能降下来好几个百分点这在高并发场景下直接转化为吞吐量提升。2.2 什么场景值得配HugePages数据库、JVM与Redis的取舍不是所有 Linux 系统都需要配 HugePages。我一般用一条经验判断单进程常驻内存超过 1GB并且对延迟敏感就值得配。这里说的“常驻”不是任务管理器里显示的 RSS而是这个进程主动向系统申请并且会持续占用的那部分内存。最典型的受益者是共享内存型数据库。Oracle 把 SGA 放在共享内存段里PostgreSQL 的 shared_buffers 和 WAL buffer 也是大块常驻内存这些进程配 HugePages 后收益最明显。其次是 JVM 系中间件WebLogic、Tomcat 配了几十 GB 堆内存的话大页能减少 GC 之外的额外 CPU 消耗。再就是自己做 mmap 映射大文件的搜索或缓存服务页表项巨大时同样值得调整。反过来有些场景我反而不建议开。容器环境里每个 Pod 被 CGroup 限制到几百 MB 内存的时候大页池的 2MB 粒度会导致无法均匀分配内存碎片反而更严重。单纯跑 Nginx 这类进程本身内存占用很小的服务配大页收益微乎其微还额外占用了不可换出的内存池。所以配置之前先想清楚你这个进程到底是不是大内存、常驻型、延迟敏感的。这三个条件缺两个就没必要折腾。值得注意的是HugePages 和 Linux 内核的透明大页THP是两套机制。前者靠vm.nr_hugepages显式分配池子进程必须主动用mmap或共享内存的方式申请大页后者是内核自动把 4KB 页合并成 2MB 页对应用透明。对企业数据库来说THP 的在线合并行为在内存碎片多时反而可能引发性能抖动这点我会在避坑章节专门展开。2.3 为什么不建议直接改nr_hugepages就完事快速不等于随便只要一条sysctl -w vm.nr_hugepages1024就能让内核去分配大页池听上去很简单但生产环境里我从来不会这么干。原因有三层第一nr_hugepages写进去只是把“期望值”告诉内核。系统当前内存碎片较多时内核可能只分出一部分页剩下的处于deferred状态挂在一边等内存整理。你看到HugePages_Total小于期望值以为没生效实际上内核在后台慢慢挤更麻烦的是你没法随时知道它到底分到哪一步了。第二大页内存的页帧是从连续物理内存里切出来的而且这部分内存一旦分配给进程就不可换出swap。也就是说你分出去的页要等进程主动释放才会回到池里。如果一开始没算好把池子建大了想缩回来却发现进程还没退出内存就卡在那儿白白占着。第三只调nr_hugepages不处理权限和挂载点等于把池子建好了却不给进程开门的钥匙。Oracle 这类数据库通常是专用系统用户跑的不是 root不配vm.hugetlb_shm_group或ulimit -l权限shmget 调用会直接被拒绝。所以我给团队定的配置顺序永远是先确认目标进程的真实内存需求按这个需求算池子大小然后写入sysctl.d的持久化配置再处理权限与挂载最后用/proc/meminfo和进程的smaps做双重验证。每一步都有对应的检查命令缺一步后面就得多花几倍时间去排障。这个顺序也是本文第 3 章的完整落地路径。3. 快速配置HugePages的完整步骤从检查现状到生效验证的六条命令3.1 第一步用grep确认当前大页状态与物理内存布局配置之前先看这台机器现在处于什么状态。有些系统镜像或云厂商 AMI 已经在/etc/sysctl.conf里改过内核参数不查清楚就继续写可能出现两处配置互相覆盖的情况。# 查看当前系统的大页分配总量、空闲量与池大小 grep -i huge /proc/meminfo # 直接读取内核当前的池参数 cat /proc/sys/vm/nr_hugepages cat /proc/sys/vm/nr_overcommit_hugepages # 确认透明大页的开启状态后面必须处理 cat /sys/kernel/mm/transparent_hugepage/enabled第一条命令里grep -i huge /proc/meminfo会输出HugePages_Total、HugePages_Free、HugePages_Rsvd、Hugepagesize几个关键字段。Hugepagesize是当前架构下的大页粒度x86_64 上默认是 2048 kB。如果HugePages_Total一直是 0说明这台机器从来没显式分配过大页池。读取/proc/sys/vm/nr_hugepages得到的是当前大页池的目标数量注意这是“期望值”不等于实际已分配的页数。nr_overcommit_hugepages是超额分配的上限意思是在期望池之外内核还允许临时多给一些页出去这个参数在业务峰值时能救急但不建议设太大否则大页内存可能挤占普通内存。第三条关于透明大页的命令输出通常是always [madvise] never这种方括号形式方括号里就是当前生效的模式。数据库场景下我后面会要求你把 THP 关掉如果这里显示[always]现在就要记下来那是最容易被忽略的前置条件。3.2 第二步按业务内存算推荐值并写入sysctl.conf计算推荐值没有通用公式能一刀切我用的方法很简单先看目标进程当前的最大常驻内存然后向上取整到 2MB 的整数倍再加 2% 的余量。比如一台 Oracle 服务器SGA_TARGET配的 16GB进程加 PGA 后 RSS 峰值约 17GB那大页池就按 18GB 建换算成 2MB 页就是 9216 个页。# 把大页池设为 9216 个 2MB 页约 18GB并允许临时超额 512 个页 echo vm.nr_hugepages 9216 /etc/sysctl.d/99-hugepages.conf echo vm.nr_overcommit_hugepages 512 /etc/sysctl.d/99-hugepages.conf echo vm.hugetlb_shm_group 54321 /etc/sysctl.d/99-hugepages.conf # 重载 sysctl 配置并确认生效 sysctl -p /etc/sysctl.d/99-hugepages.conf为什么用/etc/sysctl.d/99-hugepages.conf而不是直接改/etc/sysctl.conf因为sysctl.d目录是 kernel 推荐的覆盖式配置入口文件名以 99 开头能确保在通用配置之后被读取后续系统升级也不会被覆盖。vm.nr_hugepages是池子大小的基准页数vm.nr_overcommit_hugepages是允许超额分配的页数vm.hugetlb_shm_group是允许使用大页共享内存的组 ID我这里假设数据库用户所属的组 ID 是 54321你需要用id oracle这类命令查到真实值再替换。执行sysctl -p后内核会尽力去分配指定数量的大页。这里有个常见等待因为内存碎片你运行完命令后立刻去看/proc/meminfoHugePages_Total很可能小于 9216。这是正常现象内核后续会在内存整理完成后补上但你不应该等它慢慢补应该主动做一次内存规整我放在第 5 章坑 2 里讲。3.3 第三步挂载hugetlbfs并验证实例进程成功映射大页池建好之后还要给应用提供使用它的入口。最常见的做法是挂载hugetlbfs文件系统到/dev/hugepages数据库或 JVM 会在这个路径上创建文件来做内存映射。另外要给目标进程的属主配置好权限否则非 root 用户拿不到大页。# 创建挂载点并挂载 hugetlbfs权限 1770 表示组内共享、其他用户不可访问 mkdir -p /dev/hugepages mount -t hugetlbfs hugetlbfs /dev/hugepages # 写入 fstab保证系统重启后挂载不丢 echo hugetlbfs /dev/hugepages hugetlbfs mode1770,gid54321 0 0 /etc/fstab # 重载让 hugetlb_shm_group 生效然后检查一次 sysctl -p /etc/sysctl.d/99-hugepages.conf grep -E HugePages_Total|HugePages_Free|HugePages_Rsvd /proc/meminfomount命令中的mode1770和gid54321两个参数是生产环境必须写的。1770中的 1 是 sticky bit确保目录里每个进程只能删除自己创建的文件770表示只有组内用户能读写执行防止其他系统用户往大页文件系统里塞东西gid必须和上面vm.hugetlb_shm_group保持一致。如果漏掉gid默认属主是 root 组数据库专用用户就碰不到这个大页池了。验证映射是否成功最好的办法是重启目标实例然后看进程实际的页映射。比如 Oracle启动后检查单个后台进程的smaps文件里面应该出现大量 2048 kB 的映射段。如果进程确实起来了但映射的是普通 4KB 页说明权限或参数没生效这时候再回头看vm.hugetlb_shm_group是否和进程的属组一致。这也是为什么我强烈建议你在配置前先把id查清楚组件一旦跑起来权限错位很难一眼看出来。4. 配置HugePages后的验证与参数调优别只看free要看实际映射4.1 用/proc/meminfo确认大页分配成功free -h只能看到常规内存的分配概况看 HugePages 必须回到/proc/meminfo。配置完成后我每次上线前都会固定跑这一组命令确认池子状态稳定而不是刚配置完那一瞬间的数字。grep -E HugePages_Total|HugePages_Free|HugePages_Rsvd|HugePages_Surp|Hugepagesize /proc/meminfo当一个 18GB 的大页池建好后你应该看到HugePages_Total等于你配置的页数比如 9216HugePages_Free接近同样的数值——这些页还没被进程领取。HugePages_Rsvd是被共享内存段预留给具体进程的页数当 Oracle 启动后这个值会往上涨而HugePages_Free会相应往下掉。如果HugePages_Total长时间小于你写的目标值就要怀疑内存碎片和nr_hugepages期望值之间的差距这属于没分到位不是配置格式错误。HugePages_Surp这个字段很多人忽略它记录的是超过nr_hugepages限制额外分配出去的页数。它涨起来说明nr_overcommit_hugepages在起作用如果它长期大于 0说明你的基准池子设小了业务在靠超额分配撑着这种情况下需要把基准值往上调而不是依赖超额池一直兜底。Hugepagesize必须确认是 2048 kB除非你在 x86 分页上通过内核启动参数改成 1GB 大页。如果你的数据库进程是按照 2MB 页来计算的而这里显示的是 1GB那你建的池子页数对应的内存总量会完全错位业务直接分配失败。我在一台上了新补丁的服务器上遇到过 GRUB 默认参数被改的情况所以这个值每次上线前我都会亲自看一眼。4.2 用smaps检查进程实际映射池子建好只能说明内核把这批页准备出来了还不能证明业务进程真的用上了。判断大页是否真正生效要看进程的页表映射。每个进程的映射明细都放在/proc/pid/smaps里找到目标服务的主进程后看里面有没有 2048 kB 的映射段。# 找到 oracle 的主进程 PID pgrep -f ora_pmon|oracle | head -1 # 查看该进程 smaps 中带 huge 标记的行 grep -B5 -A5 -i huge /proc/pid/smaps | head -60smaps里与 HugePages 相关的映射行有几种典型表现。对 Oracle 来说SGA 映射到的文件路径通常包含/SYSV或直接是大页文件系统/dev/hugepages/...对应的映射段大小是 2048 kB 的整数倍对 Java 应用来说如果你通过-XX:UseLargePages开启了 JVM 大页支持smaps中会出现大量 2048 kB 的AnonHugePages之外的显式大页映射。一个关键判断点AnonHugePages不等于HugePages。前者可能是透明大页THP自动合并出来的 2MB 匿名页后者才是走hugetlbfs或共享内存显式分配的 HugePages。如果你的数据库确实开了大页却在smaps中只看到AnonHugePages而看不到显式大页映射段那就要按第 5 章坑 1 的方向去排查了。4.3 参数微调overcommit、shm_group与sysctl持久化的细节配置完成后线上运行一段时间你还需要根据实际观测微调参数。最常见的两个调整目标vm.nr_overcommit_hugepages和vm.hugetlb_shm_group。前者在业务峰值期如果看到HugePages_Surp频繁大于 0可以适当增加额度后者在你新增了多个业务用户时要把所有需要共享大页的组都加进去或者统一权限模型。# 临时调高超额分配额度先观察再决定是否写持久化 sysctl -w vm.nr_overcommit_hugepages1024 # 确认修改已生效 cat /proc/sys/vm/nr_overcommit_hugepages # 如果需要持久化追加到已有配置文件并重载 echo vm.nr_overcommit_hugepages 1024 /etc/sysctl.d/99-hugepages.conf sysctl --system这里要特别说明sysctl -w和写配置文件再sysctl --system的区别。-w只改运行时值重启后丢失写配置文件再执行sysctl --system才是完整的持久化流程。不少运维图省事只跑-w结果节点重启后大页池缩回默认值数据库起来直接失败这就是典型的“配置失效”事故。还有一个容易被忽略的细节sysctl --system会按目录遍历顺序应用所有配置文件名前缀决定了加载顺序99 这个编号在大多数发行版里都是最后加载的保证你的值能覆盖可能存在的默认配置。如果你在别的路径看到同名参数被改了却不知道为什么多半是加载顺序问题用sysctl -a | grep huge可以查实际生效值。5. 配置HugePages的避坑记录透明大页、内存碎片和数据库参数三处翻车点5.1 坑1THP没关业务进程照样翻车现象按照标准流程配置完vm.nr_hugepages挂载也做了数据库实例成功启动但top里 CPU 的 sy 占比没有明显变化查看进程smaps时发现映射的不是显式大页而是AnonHugePages。原因系统开启了透明大页THP内核的khugepaged后台线程会把进程的匿名页自动合并成 2MB 的大页。这个动作看起来让进程“用上了大页”但合并过程需要扫描进程内存并在内存碎片时不停做迁移CPU 开销反而更高。更关键的是THP 的页是自动申请的跟显式 HugePages 池完全是两条路径你建的池子根本没被进程摸到业务没有得到预期收益。解决在 GRUB 内核启动参数里加transparent_hugepagenever同时关闭khugepaged服务然后重启节点。需要说明的是部分发行版比如某些版本的 CentOS/RHEL在启动参数设了之后还需要检查/sys/kernel/mm/transparent_hugepage/enabled确实显示never才算成功光改 grub 不执行grub2-mkconfig等于没改。具体命令我在第 6 章给出。5.2 坑2内存碎片导致HugePages分配失败现象修改sysctl -w vm.nr_hugepages9216后/proc/meminfo显示HugePages_Total只有 6000 多而且dmesg日志里能看到Huge Pages allocation failed这类信息数据库启动时因共享内存不足报out of memory。原因大页池需要从物理内存的连续区域中切出 2MB 的页帧系统运行时间长了之后内存被拆得七零八落没有足够多的连续 2MB 块满足大页分配。内核此时会把这部分请求放在deferred状态等内存整理后再补但数据库启动等不了那么久。解决主动触发一次内存规整把内存碎片压缩掉给大页分配创造条件。这在生产环境是需要谨慎的操作我一般选在业务低峰期执行。# 先触发内存压缩需要 root执行后立即检查大页分配 echo 1 /proc/sys/vm/compact_memory sysctl -w vm.nr_hugepages9216 # 如果 compact 后仍差很多顺手释放 page cache 再试一次 echo 3 /proc/sys/vm/drop_caches sysctl -w vm.nr_hugepages9216 # 确认是否分配到位 grep -E HugePages_Total|HugePages_Free /proc/meminfocompact_memory是让内核去做内存规整的命令把分散的空闲页往一起挪drop_caches值为 3 表示释放页缓存和目录项缓存腾出更多可连续分配的内存。这两条命令的风险点在于drop_caches会让文件缓存失效执行后磁盘 IO 可能短暂升高compact_memory在某些内核版本上短时间内会占用 CPU 做页迁移。所以我加了一句“业务低峰期执行”不是套话。更稳妥的办法是把vm.nr_hugepages写进第 6 章的 GRUB 启动参数里让内核在开机时、内存碎片几乎不存在的最早阶段就把大页池建好。这是彻底解决碎片问题的姿势。5.3 坑3数据库SGA参数与大页池不匹配现象Oracle 实例启动失败告警日志报ORA-27102: out of memory或者实例起来了但V$SGA显示部分内存仍在使用普通页。原因SGA_TARGET设得比大页池总量还大或者 SGA 里包含了一些无法用大页映射的部分比如某些内部的reduction内存。Oracle 对共享内存段映射大页时要求整个段都落在大页里只要段尾多出哪怕一页落在了普通内存就会报错或回退。解决先把数据库启动到nomount状态查看真实的共享内存段大小再让大页池总量覆盖它并留出一定余量。我的习惯是池子大小比 SGA 预期值大 2% 到 5%因为共享内存段实际映射时会有页对齐的额外开销。# 在 SGA 从相关隐藏参数或文档确定前先按实际共享内存挂载段核查 ipcs -m | grep oracleipcs -m能看到当前由 oracle 用户创建的共享内存段的字节数把这个值除以 2MB 得到需要的页数再对照HugePages_Total。如果差了 1 到 2 个页就把nr_hugepages补上去。数据库这类场景的兜底原则大页池宁多勿少但不要多到吃光普通内存导致系统整体无内存可用——我一般控制在总物理内存的 50% 以内。5.4 坑4共享内存权限与内存锁定不足现象数据库进程在非 root 用户下启动shmget报Cannot allocate memory或Operation not permitted进程起不来即使起来了做过大页映射的线程在vmstat里看到 si/so 持续不为 0说明内存还是落到了 swap。原因大页映射的共享内存默认只有 root 有权限操作或ulimit -l的锁定内存上限不够。大页内存本来是不可换出的如果进程因为权限不够没用上大页而是带着普通内存运转被换出的风险就回来了。解决在前面的配置里给vm.hugetlb_shm_group指定业务组并确认ulimit -l上限不低于大页池大小。用 systemd 管理服务时在 service 文件里显式加LimitMEMLOCKinfinity普通 shell 启动则编辑/etc/security/limits.conf里的memlock行。这几个位置漏一处进程表面能起来但实际没拿到大页排查起来比启动失败更隐蔽。6. 让HugePages开机自动生效的进阶技巧把配置写进grub与systemd的两种可靠姿势sysctl.d的配置在系统启动阶段也能起作用因为systemd-sysctl服务会在开机时加载这些文件。但这里有个时序问题加载 sysctl 配置时内核已经运行起来了内存碎片已经存在nr_hugepages很可能又被丢进deferred状态慢慢补。要想从根上消除碎片干扰就得把大页池的创建提前到内核初始化的早期阶段也就是通过 GRUB 内核启动参数来指定。# 编辑 GRUB 配置在大页相关参数中追加 hugepagesN # N 为期望的页数比如 9216 sudo vi /etc/default/grub # 找到 GRUB_CMDLINE_LINUX 一行在引号内追加 # transparent_hugepagenever hugepages9216 GRUB_CMDLINE_LINUX... transparent_hugepagenever hugepages9216 # 重新生成引导配置UEFI 与 BIOS 发行版命令有差异 sudo grub2-mkconfig -o /boot/grub2/grub.cfg sudo reboot内核启动参数里的transparent_hugepagenever直接把 THP 关在门外面确保后续不会出现 THP 与显式 HugePages 抢内存的问题hugepages9216让内核在系统初始化阶段、物理内存几乎全部空闲时去切大页池这时候没有碎片问题分配成功率远高于系统跑起来之后再写 sysctl。重启之后再用/proc/meminfo确认HugePages_Total如果显示的页数等于你启动参数写的值这条路就走通了。如果你的业务进程不是数据库这类用共享内存的系统而是自己用hugetlbfs做内存映射的 Java 或自研 C 服务还有一个更灵活的做法用 systemd 服务在业务进程启动前预留大页并挂载。这个方案的好处是不需要重启节点适合不能随便重启的存量机器。# /etc/systemd/system/hugepages-setup.service [Unit] DescriptionReserve HugePages before application starts Beforemyapp.service [Service] Typeoneshot ExecStart/usr/sbin/sysctl -w vm.nr_hugepages2048 ExecStart/usr/bin/mount -t hugetlbfs hugetlbfs /dev/hugepages -o mode1770,gid54321 RemainAfterExityes [Install] WantedBymulti-user.target这个 service 文件我一般会在新装业务节点时配合业务进程的 systemd unit 一起写用Beforemyapp.service保证业务起之前大页已经就绪。需要注意的是同一台机器如果同时有数据库和 Java 服务要分大页池nr_hugepages只能写一个总量具体哪个进程拿到多少页要靠进程的启动顺序和申请量来竞争这时最好把池子建大一点并通过各自服务配置里的-XX:LargePageSizeInBytes2m这类参数去限制申请粒度。到现在为止我每新装一台数据库或大内存中间件服务器第一件事永远是先确认 HugePages 再装业务顺序错了我宁可推倒重来也不想在业务跑起来之后再去碰内核参数。这套流程我走了很多年踩过的坑都在前面这些章节里了希望帮到你。本文还有配套的精品资源点击获取