银河麒麟服务器V10SP2透明大页配置实战200MB内存消失之谜第一次在银河麒麟高级服务器操作系统V10SP2上配置透明大页时我盯着free -h的输出愣住了——明明只设置了100个大页系统可用内存却凭空少了200MB。这背后的原理是什么如何在提升性能的同时避免内存浪费让我们从这次踩坑经历说起。1. 透明大页的本质与内存分配机制那天下午我在一台16GB内存的X86架构银河麒麟服务器上执行了这条命令sysctl -w vm.nr_hugepages100随后立即检查内存状态free -h输出结果让我心头一紧total used free shared buff/cache available Mem: 15Gi 1.2Gi 12Gi 45Mi 1.8Gi 13Gi Swap: 2.0Gi 0B 2.0Gi对比设置前的数据可用内存available减少了整整200MB。这200MB去哪了答案藏在/proc/meminfo中cat /proc/meminfo | grep Huge输出显示HugePages_Total: 100 HugePages_Free: 100 Hugepagesize: 2048 kB Hugetlb: 204800 kB关键发现每个大页默认2MBX86架构100个大页 × 2MB 200MB这200MB被标记为HugetlbHuge TLB专用内存透明大页与传统内存管理的核心区别在于特性标准内存页透明大页页大小4KB2MBX86分配方式动态预分配TLB命中率较低高管理开销较大小适用场景通用大内存应用2. NUMA架构下的隐藏陷阱在多NUMA节点服务器上情况会更复杂。我曾在一台双路服务器上配置200个大页结果发现numactl -H | grep available输出显示有两个节点node 0 cpus: 0-23 node 1 cpus: 0-23此时设置vm.nr_hugepages200实际每个NUMA节点都会预留200个大页总共占用200页 × 2节点 × 2MB 800MB解决方案查看NUMA节点数lscpu | grep NUMA按需分配各节点大页echo 100 /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages echo 100 /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages3. 内存规划黄金法则经过多次实践我总结出大页配置的三三制原则三个必须检查当前大页使用情况grep Huge /proc/meminfo应用实际需求pmap -x $(pgrep oracle) | grep -i huge系统剩余内存free -h三个计算公式最大可分配大页数(可用内存 - 系统预留) / Hugepagesize推荐配置量应用实际使用量 × 1.2NUMA均衡公式单节点页数 总页数 / NUMA节点数三个避坑要点避免在内存紧张的服务器配置大页不要超过物理内存的20%数据库应用建议使用标准大页而非透明大页4. 性能调优实战案例某次性能优化中我们对Kylin V10SP2上的MySQL进行调优初始状态HugePages_Total: 0 MySQL性能1200 QPS配置后# 计算需要的大页数量 mysql_mem_mb2048 hugepages$(( (mysql_mem_mb * 1024) / 2048 10 )) # 应用配置 sysctl -w vm.nr_hugepages$hugepages systemctl restart mysqld效果对比指标配置前配置后提升幅度QPS1200185054%平均延迟(ms)8.25.434%TLB缺失率3.2%0.7%78%关键监测命令# 实时监控大页使用 watch -n 1 grep -E HugePages_Total|HugePages_Free /proc/meminfo # 查看TLB状态 perf stat -e dTLB-load-misses,dTLB-store-misses -p $(pgrep mysqld)5. 疑难问题排查指南遇到大页相关问题可以按照以下流程排查检查基础配置cat /sys/kernel/mm/transparent_hugepage/enabled cat /proc/meminfo | grep Huge验证NUMA分布for node in /sys/devices/system/node/node*/hugepages/hugepages-2048kB/nr_hugepages; do echo $node: $(cat $node); done分析内存占用# 按进程查看大页使用 awk /^[0-9]/ {print $1} /proc/*/smaps | sort -n | uniq -c | sort -nr | head常见错误处理问题Cannot allocate memory错误解决减少vm.nr_hugepages值或释放内存问题大页碎片化解决重启服务或使用compact_memoryecho 1 /proc/sys/vm/compact_memory问题应用无法使用大页解决检查应用是否链接了libhugetlbfs最后记住在银河麒麟V10SP2上不同架构的默认页大小不同架构默认页大小X862MBARM512MB 运维避坑实录：在银河麒麟服务器V10SP2上配置透明大页，我的200MB内存去哪了？
银河麒麟服务器V10SP2透明大页配置实战200MB内存消失之谜第一次在银河麒麟高级服务器操作系统V10SP2上配置透明大页时我盯着free -h的输出愣住了——明明只设置了100个大页系统可用内存却凭空少了200MB。这背后的原理是什么如何在提升性能的同时避免内存浪费让我们从这次踩坑经历说起。1. 透明大页的本质与内存分配机制那天下午我在一台16GB内存的X86架构银河麒麟服务器上执行了这条命令sysctl -w vm.nr_hugepages100随后立即检查内存状态free -h输出结果让我心头一紧total used free shared buff/cache available Mem: 15Gi 1.2Gi 12Gi 45Mi 1.8Gi 13Gi Swap: 2.0Gi 0B 2.0Gi对比设置前的数据可用内存available减少了整整200MB。这200MB去哪了答案藏在/proc/meminfo中cat /proc/meminfo | grep Huge输出显示HugePages_Total: 100 HugePages_Free: 100 Hugepagesize: 2048 kB Hugetlb: 204800 kB关键发现每个大页默认2MBX86架构100个大页 × 2MB 200MB这200MB被标记为HugetlbHuge TLB专用内存透明大页与传统内存管理的核心区别在于特性标准内存页透明大页页大小4KB2MBX86分配方式动态预分配TLB命中率较低高管理开销较大小适用场景通用大内存应用2. NUMA架构下的隐藏陷阱在多NUMA节点服务器上情况会更复杂。我曾在一台双路服务器上配置200个大页结果发现numactl -H | grep available输出显示有两个节点node 0 cpus: 0-23 node 1 cpus: 0-23此时设置vm.nr_hugepages200实际每个NUMA节点都会预留200个大页总共占用200页 × 2节点 × 2MB 800MB解决方案查看NUMA节点数lscpu | grep NUMA按需分配各节点大页echo 100 /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages echo 100 /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages3. 内存规划黄金法则经过多次实践我总结出大页配置的三三制原则三个必须检查当前大页使用情况grep Huge /proc/meminfo应用实际需求pmap -x $(pgrep oracle) | grep -i huge系统剩余内存free -h三个计算公式最大可分配大页数(可用内存 - 系统预留) / Hugepagesize推荐配置量应用实际使用量 × 1.2NUMA均衡公式单节点页数 总页数 / NUMA节点数三个避坑要点避免在内存紧张的服务器配置大页不要超过物理内存的20%数据库应用建议使用标准大页而非透明大页4. 性能调优实战案例某次性能优化中我们对Kylin V10SP2上的MySQL进行调优初始状态HugePages_Total: 0 MySQL性能1200 QPS配置后# 计算需要的大页数量 mysql_mem_mb2048 hugepages$(( (mysql_mem_mb * 1024) / 2048 10 )) # 应用配置 sysctl -w vm.nr_hugepages$hugepages systemctl restart mysqld效果对比指标配置前配置后提升幅度QPS1200185054%平均延迟(ms)8.25.434%TLB缺失率3.2%0.7%78%关键监测命令# 实时监控大页使用 watch -n 1 grep -E HugePages_Total|HugePages_Free /proc/meminfo # 查看TLB状态 perf stat -e dTLB-load-misses,dTLB-store-misses -p $(pgrep mysqld)5. 疑难问题排查指南遇到大页相关问题可以按照以下流程排查检查基础配置cat /sys/kernel/mm/transparent_hugepage/enabled cat /proc/meminfo | grep Huge验证NUMA分布for node in /sys/devices/system/node/node*/hugepages/hugepages-2048kB/nr_hugepages; do echo $node: $(cat $node); done分析内存占用# 按进程查看大页使用 awk /^[0-9]/ {print $1} /proc/*/smaps | sort -n | uniq -c | sort -nr | head常见错误处理问题Cannot allocate memory错误解决减少vm.nr_hugepages值或释放内存问题大页碎片化解决重启服务或使用compact_memoryecho 1 /proc/sys/vm/compact_memory问题应用无法使用大页解决检查应用是否链接了libhugetlbfs最后记住在银河麒麟V10SP2上不同架构的默认页大小不同架构默认页大小X862MBARM512MB