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)

本文来自云栖社区合作伙伴“DBGEEK”