Hugepages详情

本文介绍了Hugepages在Linux内核2.6之后引入的原因及其在数据库系统中的优势,包括减少页表大小、提高TLB命中率及避免内存交换等。文章还详细解释了在数据库服务器上使用Hugepages时应注意的问题,并提供了设置步骤。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Hugepages是从Linux kernal 2.6后被引入的,其目的是使用更大的memory page size以适应越来越大的系统内存。

在我上大学那会,买一条64M 133Mhz的内存(对,你没看错,64M)价格为500多人民币,而现在4G 1600Mhz的内存的价格也就500多。

计算机硬件的发展速度太快了,所以操作系统的一些配置也要相应的随之改变。

Linux下,默认的page size大小为4k。显然对于现在的SGA比较大的数据库系统来说,4kpage size有点太小了。

我们来看看两者之间有什么区别

1. Page Table大小

Page Table是用来存放虚拟内存也和物理内存页对应关系的内存结构。因为page size较小,所以相应的改内存结构也会比较大。

Hugepages的常见page size2M,是4k size500倍,所以可以大大减小page tablesize

我们来看两个例子:

这是一个没有配置Hugepage的系统,系统内存128Gpagetable大小大约为4G

cat /proc/meminfo

MemTotal: 132086880 kB
PageTables: 4059612 kB

这是配置了Hugepage的系统,系统内存96G, PageTable大小仅为78M

MemTotal: 98999880 kB
PageTables: 79916 kB

2. 大大提高了CPU cache中存放的page table所覆盖的内存大小,从而提高了TLB命中率

进程的虚拟内存地址段先连接到page tables然后再连接到物理内存。所以在访问内存时需要先访问page tables得到虚拟内存和物理内存的映射关系,然后再访问物理内存。

CPU cache中有一部分TLBTranslation Lookaside Buffer)用来存放部分page table以提高这种装换的速度。因为page size变大了,所以同样大小的TLB,所覆盖的内存大小也变大了。提高了TBL命中率,也就是提高了地址转换的速度。

3. 使用Hugepages的内存页是不会被交换出去的,永远常驻在内存中,所以也减少了内存也替换的额外开销

下面再说说在数据库服务器上使用Hugepages要注意的几点

1. Hugepages是在分配后就会预留出来的,其大小一定要比服务器上所有实例的SGA总和要大,差一点都不行。

比如说Hugepages设置为90Goracle SGA91G,那么oracle在启动的时候就不会使用到这90GHugepages。这90G就浪费了。所以在设置Hugepages时要计算SGA的大小,后面会给出一个脚本来计算。

2. 其他进程无法使用Hugepages的内存,所以不要设置太大,稍稍比SGA大一点保证SGA可以使用到hugepages就好了。

3. PGA不会使用Hugepages的内存。所以11gAMM (Automatic Memory Managementmemory_target参数)是不被支持的。而ASMM(Automatic Shared Memory Management, SGA_target参数)是被支持的,这两个不要搞混淆了。

4. meminfo中和Hugepage相关的有四项(RHEL5

HugePages_Total: 43000
HugePages_Free: 29493
HugePages_Rsvd: 23550
Hugepagesize: 2048 kB

HugePages_Total为所分配的页面数目,和Hugepagesize相乘后得到所分配的内存大小。43000*2/1024大约为84GB
HugePages_Free为从来没有被使用过的Hugepages数目。即使oracle sga已经分配了这部分内存,但是如果没有实际写入,那么看到的还是Free的。这是很容易误解的地方
HugePages_Rsvd为已经被分配预留但是还没有使用的page数目。在Oracle刚刚启动时,大部分内存应该都是Reserved并且Free的,随着oracle SGA的使用,ReservedFree都会不断的降低

HugePages_Free – HugePages_Rsvd 这部分是没有被使用到的内存,如果没有其他的oracle instance,这部分内存也许永远都不会被使用到,也就是被浪费了。在该系统上有11.5GB的内存被浪费了。

Note: RHEL4上的meminfo有所区别,没有HugePages_Rsvd这一项,并且当oracle instance启动时,所分配的内存就从free list上被移除掉了。也就是启动后HugePages_Free就是没有被SGA用到被浪费的内存。

最后说说如何设置HugePages

1. 首先计算SGA大小已决定你要使用多少HugePages内存页。

你可以手工计算,如果使用了ASMM可以用SGA_Target/Hugepagesize,否则可以将db_cache_sizelarge_pool_size, shared_pool_size,jave_pool_size, streams_pool_size五个部分加起来除以Hugepagesize

或者可以先将oracle instance都起起来,然后ipcs -m查看共享内存段大小来计算。oracle401749.1中也提供了一个脚本来帮助计算,脚本如下:

#!/bin/bash
#
# hugepages_settings.sh
#
# Linux bash script to compute values for the
# recommended HugePages/HugeTLB configuration
#
# Note: This script does calculation for all shared memory
# segments available when the script is run, no matter it
# is an Oracle RDBMS shared memory segment or not.
#
# This script is provided by Doc ID 401749.1 from My Oracle Support
# http://support.oracle.com

# Welcome text
echo "
This script is provided by Doc ID 401749.1 from My Oracle Support
(http://support.oracle.com) where it is intended to compute values for
the recommended HugePages/HugeTLB configuration for the current shared
memory segments. Before proceeding with the execution please make sure
that:
* Oracle Database instance(s) are up and running
* Oracle Database 11g Automatic Memory Management (AMM) is not setup
(See Doc ID 749851.1)
* The shared memory segments can be listed by command:
# ipcs -m

Press Enter to proceed..."

read

# Check for the kernel version
KERN=`uname -r | awk -F. '{ printf("%d.%d\n",$1,$2); }'`

# Find out the HugePage size
HPG_SZ=`grep Hugepagesize /proc/meminfo | awk '{print $2}'`

# Initialize the counter
NUM_PG=0

# Cumulative number of pages required to handle the running shared memory segments
for SEG_BYTES in `ipcs -m | awk '{print $5}' | grep "[0-9][0-9]*"`
do
MIN_PG=`echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -q`
if [ $MIN_PG -gt 0 ]; then
NUM_PG=`echo "$NUM_PG+$MIN_PG+1" | bc -q`
fi
done

RES_BYTES=`echo "$NUM_PG * $HPG_SZ * 1024" | bc -q`

# An SGA less than 100MB does not make sense
# Bail out if that is the case
if [ $RES_BYTES -lt 100000000 ]; then
echo "***********"
echo "** ERROR **"
echo "***********"
echo "Sorry! There are not enough total of shared memory segments allocated for
HugePages configuration. HugePages can only be used for shared memory segments
that you can list by command:

# ipcs -m

of a size that can match an Oracle Database SGA. Please make sure that:
* Oracle Database instance is up and running
* Oracle Database 11g Automatic Memory Management (AMM) is not configured"
exit 1
fi

# Finish with results
case $KERN in
'2.4') HUGETLB_POOL=`echo "$NUM_PG*$HPG_SZ/1024" | bc -q`;
echo "Recommended setting: vm.hugetlb_pool = $HUGETLB_POOL" ;;
'2.6') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
*) echo "Unrecognized kernel version $KERN. Exiting." ;;
esac

# End

2. 关闭所有oracle实例

3. root设定oracle memlock limit,设置一个较大的数值或者unlimited

/etc/security/limits.conf最后添加(如:设置pagesize110000 pages,则limit=11000*2M*1824 ,其中)
oracle hard  memlock  unlimited
oracle soft memlock unlimited 

4. 分配hugepages内存

#/etc/sysctl.conf中添加

vm.nr_hugepages=11000

#在RHEL4 是直接设置hugepage的页数每页大小为2M,

执行sysctl -p使其生效。这时候内存就已经被分配了,可以查看meminfo

grep Huge /proc/meminfo

HugePages_Total为设定的值大小,HugePages_Free应该和HugePages_Total一样大,HugePages_Rsvd0.

5. 启动Oracle instance

这时候再次查看meminfo

HugePages_Total为设定的值大小不变,HugePages_Free有所降低,HugePages_Rsvd为一个较大的数值(因为刚刚启动时,大部分SGA被分配但是没有被使用到)。

如果Hugepages没有被使用,可能一些memory page被分配为4k大小了,那么需要重启server来设置。

从我们的测试结果看,Hugepages可以提高OLTP系统10%的吞吐量,当然不同的数据库应用结果可能不同,但是总体来说这是一个nice to have的设置

 

 

查看SGA总和:

SQL> show sga

Total System Global Area 171966464 bytes
Fixed Size 787988 bytes
Variable Size 145750508 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes

--查询总和
select sum(value)/1024/1024 "total sga md" from v$sga;

[root@k8s-master-node1 ~]# kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME k8s-master-node1 Ready control-plane,master,worker 12m v1.22.1 192.168.200.13 <none> CentOS Linux 7 (Core) 3.10.0-1062.el7.x86_64 docker://20.10.9 [root@k8s-master-node1 ~]# kubectl describe node master Error from server (NotFound): nodes "master" not found [root@k8s-master-node1 ~]# kubectl describe node 192.168.200.13 Error from server (NotFound): nodes "192.168.200.13" not found [root@k8s-master-node1 ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION k8s-master-node1 Ready control-plane,master,worker 13m v1.22.1 [root@k8s-master-node1 ~]# kubectl describe node k8s-master-node1 Name: k8s-master-node1 Roles: control-plane,master,worker Labels: beta.kubernetes.io/arch=amd64 beta.kubernetes.io/os=linux kubernetes.io/arch=amd64 kubernetes.io/hostname=k8s-master-node1 kubernetes.io/os=linux node-role.kubernetes.io/control-plane= node-role.kubernetes.io/master= node-role.kubernetes.io/worker= node.kubernetes.io/exclude-from-external-load-balancers= Annotations: flannel.alpha.coreos.com/backend-data: {"VNI":1,"VtepMAC":"ba:7a:02:98:65:de"} flannel.alpha.coreos.com/backend-type: vxlan flannel.alpha.coreos.com/kube-subnet-manager: true flannel.alpha.coreos.com/public-ip: 192.168.200.13 kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock node.alpha.kubernetes.io/ttl: 0 volumes.kubernetes.io/controller-managed-attach-detach: true CreationTimestamp: Thu, 31 Jul 2025 10:15:21 +0800 Taints: <none> Unschedulable: false Lease: HolderIdentity: k8s-master-node1 AcquireTime: <unset> RenewTime: Thu, 31 Jul 2025 10:29:30 +0800 Conditions: Type Status LastHeartbeatTime LastTransitionTime Reason Message ---- ------ ----------------- ------------------ ------ ------- NetworkUnavailable False Thu, 31 Jul 2025 10:15:44 +0800 Thu, 31 Jul 2025 10:15:44 +0800 FlannelIsUp Flannel is running on this node MemoryPressure False Thu, 31 Jul 2025 10:25:35 +0800 Thu, 31 Jul 2025 10:15:19 +0800 KubeletHasSufficientMemory kubelet has sufficient memory available DiskPressure False Thu, 31 Jul 2025 10:25:35 +0800 Thu, 31 Jul 2025 10:15:19 +0800 KubeletHasNoDiskPressure kubelet has no disk pressure PIDPressure False Thu, 31 Jul 2025 10:25:35 +0800 Thu, 31 Jul 2025 10:15:19 +0800 KubeletHasSufficientPID kubelet has sufficient PID available Ready True Thu, 31 Jul 2025 10:25:35 +0800 Thu, 31 Jul 2025 10:15:34 +0800 KubeletReady kubelet is posting ready status Addresses: InternalIP: 192.168.200.13 Hostname: k8s-master-node1 Capacity: cpu: 2 ephemeral-storage: 51175Mi hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 1863100Ki pods: 110 Allocatable: cpu: 2 ephemeral-storage: 48294789041 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 1760700Ki pods: 110 System Info: Machine ID: aed7f180110d4207925b8b6ffb5e04e7 System UUID: 326C4D56-3645-80DE-DA14-9E7FCF9952A9 Boot ID: f9cacd8a-e24c-4f56-9e30-7388c70acfe9 Kernel Version: 3.10.0-1062.el7.x86_64 OS Image: CentOS Linux 7 (Core) Operating System: linux Architecture: amd64 Container Runtime Version: docker://20.10.9 Kubelet Version: v1.22.1 Kube-Proxy Version: v1.22.1 PodCIDR: 10.244.0.0/24 PodCIDRs: 10.244.0.0/24 Non-terminated Pods: (12 in total) Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits Age --------- ---- ------------ ---------- --------------- ------------- --- dashboard-cn dashboard-agent-cd88cf454-qg6mv 0 (0%) 0 (0%) 0 (0%) 0 (0%) 13m dashboard-cn dashboard-cn-64bd46887f-kmjwm 0 (0%) 0 (0%) 0 (0%) 0 (0%) 13m dashboard-en dashboard-en-55596d469-cc22g 0 (0%) 0 (0%) 0 (0%) 0 (0%) 13m kube-system coredns-78fcd69978-8s9xt 100m (5%) 0 (0%) 70Mi (4%) 170Mi (9%) 13m kube-system coredns-78fcd69978-mkg6d 100m (5%) 0 (0%) 70Mi (4%) 170Mi (9%) 13m kube-system etcd-k8s-master-node1 100m (5%) 0 (0%) 100Mi (5%) 0 (0%) 14m kube-system kube-apiserver-k8s-master-node1 250m (12%) 0 (0%) 0 (0%) 0 (0%) 14m kube-system kube-controller-manager-k8s-master-node1 200m (10%) 0 (0%) 0 (0%) 0 (0%) 14m kube-system kube-flannel-ds-dm28d 100m (5%) 100m (5%) 50Mi (2%) 50Mi (2%) 13m kube-system kube-proxy-4hznc 0 (0%) 0 (0%) 0 (0%) 0 (0%) 13m kube-system kube-scheduler-k8s-master-node1 100m (5%) 0 (0%) 0 (0%) 0 (0%) 14m kube-system metrics-server-77564bc84d-ddcbl 0 (0%) 0 (0%) 0 (0%) 0 (0%) 13m Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 950m (47%) 100m (5%) memory 290Mi (16%) 390Mi (22%) ephemeral-storage 0 (0%) 0 (0%) hugepages-1Gi 0 (0%) 0 (0%) hugepages-2Mi 0 (0%) 0 (0%) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning SystemOOM 14m (x9 over 14m) kubelet (combined from similar events): System OOM encountered, victim process: portainer, pid: 11953 Normal Starting 14m kubelet Starting kubelet. Warning SystemOOM 14m kubelet System OOM encountered, victim process: virt-controller, pid: 6419 Warning SystemOOM 14m kubelet System OOM encountered, victim process: virt-controller, pid: 6503 Warning SystemOOM 14m kubelet System OOM encountered, victim process: portainer, pid: 9051 Warning SystemOOM 14m kubelet System OOM encountered, victim process: virt-api, pid: 6382 Warning SystemOOM 14m kubelet System OOM encountered, victim process: virt-handler, pid: 9060 Warning SystemOOM 14m kubelet System OOM encountered, victim process: runc:[2:INIT], pid: 9670 Warning SystemOOM 14m kubelet System OOM encountered, victim process: runc:[2:INIT], pid: 9678 Warning SystemOOM 14m kubelet System OOM encountered, victim process: portainer, pid: 9426 Warning SystemOOM 14m kubelet System OOM encountered, victim process: portainer, pid: 9534 Warning SystemOOM 14m (x15 over 14m) kubelet (combined from similar events): System OOM encountered, victim process: virt-api, pid: 10256 [root@k8s-master-node1 ~]# ssh master systemctl status kubelet ssh: Could not resolve hostname master: Name or service not known [root@k8s-master-node1 ~]#
最新发布
08-01
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值