一、内存耗尽场景
问题现象：
Oracle数据库服务器内存资源耗尽，数据库无响应。
问题原因：
原linux环境没有启用HugePages，启用HugePages后，内存使用率直线上涨，最终内存资源耗尽。
启用HugePages明明是提高性能，为什么会导致内存资源耗尽呢？这和HugePages内存分配机制有关：
例如当前配置信息如下：
数据库服务器总内存128GB，SGA分配75GB，PGA分配30GB，SGA+PGA占总内存82%。
通常启用HugePages大页时，会将HugePages设置为偏大于SGA值，例如76G。
但如果设置HugePages比SGA值小，会出现什么情况？
例如：将HugePages设置为70GB。
此时服务器内存最大会分出70GB给HugePages使用，但是由于HugePages<SGA，导致Oracle数据库不会完全使用HugePages中的内存来分配给SGA，出现内存资源浪费，高并发、高负载等场景下可能会导致内存资源耗尽。
在官方文档有这么一段描述：
Ensure that HugePages is configured properly as the system may run out of memory if excess HugePages is not used by the application.
确保HugePages配置正确，因为如果应用程序未使用过多的HugePage，系统可能会耗尽内存。
问题重现：
环境说明:
参数：
AMM内存管理和HugePages不兼容，如果内存启用了AMM(Automatic Memory managed)，需要先切换为ASMM(Automatic Shared Memory Managed)。
先备份参数文件：
将AMM转换为ASMM：
重启数据库：
1.1 正确启用HugePages方法：
启动前，检查基本信息
配置memlock
在/etc/security/limits.conf文件中设置memlock值，memlock设置以KB为单位。
当启用HugePages内存时，最大锁定内存限制应至少设置为当前服务器内存的90%。
禁用HugePages内存时，最大锁定内存限制应设置为至少3145728 KB（3 GB）。
例如，如果安装了64 GB RAM，则添加以下条目以增加最大锁定内存地址空间：
也可以将memlock值设置为高于SGA要求的值,或者设置为unlimited
再次以oracle用户身份登录并运行ulimit-l命令以验证新的memlock设置
检查并启动实例
RAC：
检查实例是启动状态
如果没启动，手动启动实例
单机：
使用脚本为当前共享内存段计算hugepages配置的建议值：
root用户下执行：
备注：脚本内容见末尾。
脚本来自My Oracle Support note 401749.1 。
例如：
最终计算出的vm.nr_hugepages建议值为996，tmd数字不吉利。
其中996乘以2MB=1992MB > sga_target(1970MB)
执行脚本除了看vm.nr_hugepages，也要关注下其他内容：
在执行之前，请注意以下事项：
停止数据库实例
设置vm.nr_hugepages内核参数
写入配置文件，永久生效
# sysctl -w vm.nr_hugepages=<value from above> 临时改变，重启失效。
本次示例：996
查询：
启动实例
查看alert_cjc.log日志信息：
检查可用的hugepages
如果配置没生效，需要重启服务器；
PageTables变小了；
查看内存使用
1.2 错误启用HugePages方法
如果将HugePages设置低于sga_target，例如1000MB，小于 sga_target(1970MB)。
vm.nr_hugepages值从996改为1000/2=500。
停库：
修改参数：
启库：
查看alert_cjc.log日志信息：
告警日志有如下建议：
系统全局区域的总大小为1986 MB。为了获得最佳性能，在下一次实例重新启动之前：
在系统范围内将未使用的大页面数量增加至少493个（页面大小2048 KB，总大小986 MB），以获得100%的系统全局区域分配有大页面。
查看：
页表比正确配置的偏大
使用了少量的HugePages
二、use_large_pages参数说明
默认参数：TRUE
当系统的HugePage被使用尽，只有small pages的情况下，SGA也会继续运行。此时，Oracle实例就运行在内存使用混合模式(Mixed Mode)下。
除了TURE，还支持ONLY和AUTO。
其中ONLY表示：Oracle实例只会使用HugePage作为内存使用，如果系统在AMM模式或者HugePage用尽的时候，数据库就不能启动。
测试ONLY值：
先备份参数文件：
修改参数：
重启数据库：
报错如下：
告警信息如下：
恢复备份参数文件：
重新启动数据库：
三、HugePages说明
HugePages是Linux内核2.6中集成的一个特性。
启用HugePages可以使操作系统支持大于默认值（通常为4KB）的内存页。
使用HugePages时，操作系统页表(虚拟内存到物理内存的映射)变小，可以减少访问页表条目所需的系统资源量，从而提高系统性能。
HugePage的大小从2MB到256MB不等，这取决于内核版本和硬件体系结构。
对于Oracle数据库，使用HugePages可以减少操作系统页表状态的维护，并提高Translation Lookaside Buffer（TLB）命中率。
四、何时启用HugePages
适用于：具有大型SGA和或会话较多的数据库。
许多文档将HugePages在Linux上的使用描述为一种可能性，但没有充分强调HugePage在某些数据库配置中成为一种要求。
对于一个SGA较小或连接用户数量较少的数据库（较小的“会话”），配置HugePages不会有任何改进。
但是，对于具有大SGA（2Gb以上）和许多连接用户（会话>500）的数据库，为了减少操作系统级别的内存使用并提高数据库的整体性能，必须配置HugePages。
每个会话的前台进程将具有一个称为PageTable的内存结构，该进程通过该内存结构访问SGA。
简而言之，由于Linux上的默认页面大小很小（这是英特尔的限制），应用程序使用的内存非常大，因此页面表变得太大，无法管理。
HugePages是为克服这一问题而开发的解决方案。它绝对不是内核错误。
对于使用大量SGA区域的Oracle数据库，如果不是必要的要求，则使用HugePages是最佳实践。
SGA越大，每个进程的PageTable就越大。每个进程都有这个PageTable，所以对于许多连接的会话，所有PageTable的总和将变得更大。
内存结构PageTables的总大小可以通过以下内容查看：
“free”实用程序不会显式显示这种类型的内存，但会将其包含在“cache”或“buff/cache”下的文件系统缓存中。
具有大型SGA和或许多会话的数据库必须配置HugePages。
对于性能和较小的内存占用空间，建议使用它。
它可以是具有相对低的sga_starget＝2-5Gb但具有许多会话＝1000-2000的数据库，或者具有巨大的sga_tharget＝200Gb且很少会话＝500的数据库。
在这些特定的数据库配置中，PageTables可能会消耗机器上的额外内存，该内存可能等于或大于SGA的总大小。
PageTables内存被添加到该机器上数据库消耗的SGA和总PGA内存中。
例如：
(1)数据库配置
在高峰时间（连接了近500个会话）PageTables消耗机器物理内存中的20Gb
at peak time (near 500 sessions connected) PageTables consumes 20Gb from the physical memory of the machine
因此，该数据库在高峰时段将使用25Gb（sga）+20Gb（PageTables）+10Gb（总PGA）=55Gb。
So this database at peak times would use 25Gb (sga) + 20Gb (PageTables) + 10Gb (total PGA) = 55Gb .
一台具有45Gb物理RAM的机器，我们通常认为它可以很容易地容纳具有25Gb SGA和10Gb总PGA的数据库，
将开始使用10Gb交换。性能下降，如果更多的用户连接到数据库，我们最终将没有内存。
A machine with 45Gb physical RAM, which we normally think would accommodate easily a database with 25Gb SGA and 10Gb total PGA, will start swapping using 10Gb of swap.
Performance goes down and if more users connect to the database, we would end up without memory.
(2)数据库配置
a.在配置HugePages之前，我们看到209Gb的巨大“buff/cache”几乎等于SGA
a. before configuring HugePages we see a huge 'buff/cache' of 209Gb almost equal to the SGA
b.配置HugePages后，“buff/cache”下降95%，“空闲”内存显著增加
b. after configuring HugePages, 'buff/cache' drops by 95% and 'free' memory increase considerably
(3)数据库配置
a.如果没有HugePages，在500个连接会话的情况下，PageTables会消耗机器物理内存中的2.5Gb
a. without HugePages, with 500 connected sessions, PageTables consumes 2.5Gb from the physical memory of the machine
b.配置HugePages后，在500个连接会话的情况下，PageTables仅消耗机器物理内存中的200Mb
b. after configuring HugePages, with 500 connected sessions, PageTables consumes only 200Mb from the physical memory of the machine
启用HugePages后，系统使用更少的PageTables，从而减少了维护和访问它们的开销。
Huge pages仍然固定在内存中，不会被替换，因此内核交换守护进程在管理它们时没有任何工作要做，内核也不需要为它们执行页面表查找。
较少的页面数量减少了执行内存操作所涉及的开销，也降低了访问页面表时出现瓶颈的可能性。
如果没有HugePages，操作系统会将每个4KB（通常为默认页面大小）的内存作为一个页面，当它被分配给SGA时，该页面的生命周期（dirty, free、映射到进程等）会由操作系统内核保持最新，因此会产生性能问题。
所以：
五、使用HugePages性能提升多大
下面的性能测试来自大佬"徐sir的IT之路"公众号的《如何正确的在AIX 7.x系统中开启LargePage for Oracle》文章，原文链接如下：
如何正确的在AIX 7.x系统中开启LargePage for Oracle
(1)未开启16M大页时，500用户swingbench OE v1模型测试结果
(2)开启16M大页后，500用户swingbenchOE v1模型测试结果
图片
比较下TPS由3386提升到4444，总体提升约31%左右，测试仅供参考。
六、HugePages配置的限制
Restrictions for HugePages Configurations
HugePages有以下限制：
HugePages has the following limitations:
1.必须取消设置MEMORY_TARGET和MEMORY_MAX_TARGET初始化参数。
例如，要取消设置数据库实例的参数，请使用命令ALTER SYSTEM RESET。
2.自动内存管理（AMM）和HugePages不兼容。
使用AMM时，通过在/dev/shm下创建文件来分配整个SGA内存。
当Oracle数据库使用AMM分配SGA时，不保留HugePage。
Oracle 19C使用HugePages，必须禁用AMM(11g也需要禁用AMM)。
3.如果在32位环境中使用VLM，则不能将HugePages用于Database Buffer cache。
您可以将HugePage用于SGA的其他部分，如shared_pool、large_pool等。
VLM（buffer cache）的内存分配是使用共享内存文件系统（ramfs/tmpfs/shmfs）完成的。
内存文件系统不保留或使用HugePages。
4.除非系统管理员通过修改可用页面数或修改池大小来更改HugePages配置，否则系统启动后不会分配或释放HugePages。
如果在系统启动期间内存中没有保留所需的空间，则HugePages分配失败。
5.确保HugePages配置正确，因为如果应用程序未使用过多的HugePage，系统可能会耗尽内存。
6.如果实例启动时HugePages不足，并且初始化参数use_large_pages设置为only，则数据库无法启动，并且会显示一条警报日志消息，提供有关HugePages的必要信息。
七、参考链接
官方文档位置：
Home / Database / Oracle Database Online Documentation 11g, Release 2 (11.2) / Database Administration / Database Administrator's Reference / G.2 Overview of HugePages
11g版本：
19C版本：
其他：
