X

一线数据库工程师的精彩案例分享、新特性介绍、诊断工具和诊断方法、以及常用的测试案例 -- 欢迎光临Oracle数据库中文技术支持官方微博

在Linux 64位系统下使用hugepage

首先,为什么要介绍/使用HugePage?

在步入正题之前,先讲一个非常普遍的数据库性能问题。

众所周知,Oracle数据库使用共享内存(SGA)来管理可以共享的一些资源;比如shared pool中存储了共享的SQL语句及执行计划,buffer pool中存储了数据块。对这些资源的访问,其实就是Oracle使用OSAPI来访问内存资源的过程。内存操作理应/通常意义上都是很快的,这时候Oracle数据库可以很正常的工作。

但是

a)如果SGA内的某一部分被swap到硬盘上,那么再次访问它,就需要花非常多的时间

b)如果OS本身的内存非常的大,那么管理/访问到我们需要的内存的过程就需要更长时间。

在这些情况下,我们往往会碰到诸如latch/mutex/library cache lock[pin]/row cache lock的问题.

LinuxHugePage 可以解决由以上两种问题引发的性能波动。

我们知道,在Linux 64位系统里面,默认内存是以4K的页面(Page)来管理的,当系统有非常多的内存的时候,管理这些内存的消耗就比较大;HugePage使用2M大小的页面来减小管理开销。HugePage管理的内存并不能被Swap,这就避免了swap引发的数据库性能问题。所以,如果您的系统经常碰到因为swap引发的性能问题的系统毫无疑问需要启用HugePage。另外,OS内存非常大的系统也需要启用HugePage。但是具体多大就一定需要使用HugePage?这并没有定论,有些文档曾经提到12G以上就推荐开启,我们强烈建议您在测试环境进行了充分的测试之后,再决定是否在生产环境应用HugePage

当然,任何事情都是有两面性的,HugePage也有些小缺点。第一个缺点是它需要额外配置,但是这完全是可以忽略的。另外, 如果使用了HugePage11g新特性 AMMAutomatic Memory Management)就不能使用了,但是ASMMAutomatic
Shared Memory Management
)仍然可以继续使用。

接下来,我们对配置HugePage需要完成的步骤进行介绍。以下步骤以RHEL5为例。

a) 设置memlock的限制,更改/etc/security/limits.conf加入下面的行

注意上面的数字是以 K 为单位的,可以让它的值稍微比系统的物理内存小就可以了

b) 检查memlock是否生效,要使用oracle的用户执行下面的操作,如果没有生效尝试重新登陆系统

c) 如果使用11g数据库,确认参数MEMORY_TARGETMEMORY_MAX_TARGET已经设为0

d) 启动数据库,并运行Document
401749.1
提供的脚本来计算应该分配多少HugePage页面。例如:

e) 更改/etc/sysctl.conf,把上一步得到的值指定给vm.nr_hugepages参数

f) 重启数据库和OS

g) 验证HugePage是否已启用

如下图,HugePage一共分配了1496个页面,其中有6个页面为Free,那么使用了1490个页面,每个页面为2048K.

最后,如果您想了解更多的和HugePage相关的问题,请参考以下的note

Note 361323.1 : HugePages on Linux: What It
Is... and What It Is Not...

Note 361468.1 : HugePages on Oracle Linux
64-bit 

关于这个主题,如果有后续的问题欢迎点击链接参与我们在中文社区的讨论。

Join the discussion

Comments ( 12 )
  • guest Thursday, February 28, 2013

    good


  • guest Thursday, July 17, 2014

    你好,请教一个问题:

    “HugePage管理的内存并不能被Swap,这就避免了swap引发的数据库性能问题”,不使用hugepage时内存swap是因为当前内存不足以装载更多即时内容,那为什么使用hugepage就能避免这种情况


  • guest Wednesday, July 23, 2014

    HugePage管理的内存并不能被Swap - 这是Linux提供的特性,是OS来保证的.


  • 付强 Tuesday, October 28, 2014

    AMM是oracle11g的一大亮点,可以充分利用内存,省去了内存分配的纠结。如果这个特性不能使用,那实在是太遗憾了。

    hugepage是大势所趋,Oracle要努力啊!

    ps:12c的AMM和hugepage兼容吗?


  • 付强 Tuesday, October 28, 2014

    hugepage下ASMM可以正常使用,为啥AMM就不行了呢?


  • guest Tuesday, October 28, 2014

    根据12c的文档:http://docs.oracle.com/cd/E11882_01/server.112/e10839/appi_vlm.htm#UNXAR397

    AMM和hugepage也是不兼容的。原因就是为了实现AMM,内存是分配在/dev/shm中,而这种方式的内存管理机制(Linux)和hugepage不兼容。

    这个RHEL的文档也讲了:Huge Pages pool is not being used for the ramfs shared memory file system. Hence, you do not need to increase the Huge Pages pool if you use the ramfs shared memory file system. 我认为这是OS的机制。如果Oracle用了ramfs(来实现AMM),那么就不能用hugepage.我并不清楚除了RAMFS是否还有其它OS的机制可以用来实现AMM.

    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Large_Memory_Optimization_Big_Pages_and_Huge_Pages-Huge_Pages_and_Shared_Memory_File_System_in_Red_Hat_Enterprise_Linux_3.html


  • 付强 Tuesday, October 28, 2014

    这个RHEL的文档也讲了:Huge Pages pool is not being used for the ramfs shared memory file system. Hence, you do not need to increase the Huge Pages pool if you use the ramfs shared memory file system. 我认为这是OS的机制。如果Oracle用了ramfs(来实现AMM),那么就不能用hugepage.我并不清楚除了RAMFS是否还有其它OS的机制可以用来实现AMM.

    ————————————————————————————————————————

    AMM应该是用的tmpfs吧。


  • guest Tuesday, October 28, 2014

    看来我确实错了。

    AMM是用的tmpfs, 那么问题就是tmpfs这种技术是不是可以和hugepage兼容。

    我觉得这可能还是OS的事。

    我再查查。


  • guest Wednesday, June 10, 2015

    「HugePage管理的內存並不能被Swap,這就避免了swap引發的數據庫性能問題」,那如果內存不夠用又不能Swap時會怎樣呢?


  • guest Wednesday, June 10, 2015

    「HugePage管理的內存並不能被Swap,這就避免了swap引發的數據庫性能問題」,那如果內存不夠用又不能Swap時會怎樣呢?


  • 付强 Tuesday, May 31, 2016

    开启hugepage后,数据库的memory_target(AMM)就不能用了。

    那ASM的AMM还能用呢?我试了一下,好像可以用,只是不知道这样会对ASM实例有什么影响?


  • 付强 Wednesday, June 1, 2016

    请教一个问题:ASM实例和数据库实例会共享hugepage吗?


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.