Huge page使用的一些问题

12c的数据库在安装的时候,有一个检查项目,叫做Maximum locked memory check。

这是要求设置/etc/security/limits.conf中的memlock的值,官方文档在11g要求是设置比物理内存稍小的一个值,在12c中要求至少为90%的物理内存。

而memlock的设置,是启用huge page的一部分。开启hugepage在大内存大sga的环境下,可以提供系统的性能。

启用hugepage需要设置/etc/security/limits.conf和vm.nr_hugepages(Doc ID 361468.1)

注1:
在asm中,当启用hugepage时oracle建议asm的SGA增大到至少2G,设置hugepage至少1300个以上的大页面(Doc ID 2111010.1)

在Exadata中,默认启用了hugepage,且安装Exadata的时候,就默认禁用了asm的AMM(PGA不使用hugepage,这也是为什么使用hugepage不能同时使用AMM,只能使用ASMM的原因。因为AMM是自动管理SGA+PGA。而hugepage不能被PGA使用。),设置了SGA大小为2G。(Doc ID 1681467.1)。
上述的大小只是一个大概的估算值,如果需要计算大小,也是可以计算的。asm的shared pool的大小,在150M的基础上,external冗余的disks,每增加100G的空间大小,需要额外的1M内存(Doc ID 437924.1)

注2:
在12c中grid中多了一个MGMTDB来记录GI资源信息,这个DB的SGA使用,也要考虑看hugepage的配置中。不过由于mgmtdb不确定会跑在那个节点上,在Exadata的health check检查项目中,是建议把mgmtdb使用hugepage属性关闭的。(Doc ID 1274318.1)

注3:
还有一个参数pre_page_sga,在9i~11g中默认值是false,在12c中默认值是true。在12c之前,默认值false可以避免在进程启动时,access sga中所有的page页面加快进程的启动速度(见connection management call elapsed time)。而在12.1之后,算法发生了改变,设置为true和false几乎没有差别。

注4:
上面说的hugepages,指的是regular hugepages,而对于transparent hugepages,我们是需要禁用的。见Disable Transparent HugePages on SLES11, RHEL6, RHEL7, OL6, OL7, and UEK2 and above (Doc ID 1557478.1)。
regular hugepages是提前分配,不是动态分配,transparent hugepages是通过khugepaged线程动态配置的,这可能会导致Oracle运行过程中出现一些奇怪的问题,Oracle建议关闭Transparent HugePages功能。

注5:
放在small pages上的sga,不会直接占用物理内存(这样应该是在page fault时才会申请物理内存)。即ipcs -am看到占用的内存的是在vm中,不是在RSS中,实际物理内存中。

所以,
(1)oracle推荐在大内存大sga的情况下,使用hugepage。文档上说是大于8G物理内存(Doc ID 361468.1);在实际使用中,客户如果超过64G内存,我们一般都推荐使用。
(2)对于asm我们可以设置sga至少2G,同时注意要求至少1300个以上的大页面。
(3)对于mgmtdb,我们可以设置use_large_pages=false禁用mgmtdb使用hugepage。
(4)如果多个数据库共享一个主机,但是如果我们提前把hugepage的配置能覆盖到所有instance,那么就不存在什么问题。在11g中,有use_large_page参数,默认值为true。即默认尝试配合OS使用hugepage。但是在11.2.0.2的时候,如果hugepage不够cover sga,会导致数据库启动不了。在11.2.0.3以后,oracle会在hugepage不够的情况下,将使用small page来弥补剩余的page,从而启动数据库(Doc ID 1392497.1)
(5)禁用transparent hugepages(Doc ID 1557478.1)

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据