Oracle's Configuration Hugepages memory

Hugepages uses large-page memory instead of traditional 4KB memory pages, resulting in fewer management virtual addresses, faster mapping from virtual addresses to physical addresses, and improved overall memory performance by discarding swap-in for memory pages. Especially for more than 8GB of memory and the larger Oracle SGA size, it is recommended to match the values and use the Hugepage feature. This document is based on X86_64 Linux down to describe how to match the value of Hugepages.

One, configure Hugepages for Oracle server

1.1, check whether the current system is equipped with value Hugepages
The hugepages related values in the following query are 0, indicating that there is currently no value hugepages, and then you can see Hugepagesize as 2MB.
$ grep huge/proc/meminfo
hugepages_total:0
hugepages_free:0
hugepages_rsvd:0
hugepagesize:2048 KB

1.2, modify the user's memlock limit
By modifying the/etc/security/limits.conf value file to achieve
The value of this parameter usually has a value bit less than the current installed system memory, such as the current system memory of 64GB, you can do the following settings
* Soft Memlock 60397977
* Hard Memlock 60397977
The above setting is in KB and does not degrade system performance. At a minimum, the value is slightly greater than the sum of all the SGA on the system.
Use Ulimit-l to verify this setting

1.3. Disable AMM (Oracle 11g)
If the current Oracle version is 10g, you can skip this step.
If the current Oracle version is 11g, AMM will need to be disabled because the AMM (Automatic Memory Management) feature is incompatible with hugepages.
ALTER SYSTEM RESET memory_target scope=spfile;
ALTER SYSTEM RESET memory_max_target scope=spfile;
ALTER SYSTEM SET sga_target=<n>g scope=spfile;
ALTER SYSTEM SET pga_aggregate_target=<n>g scope=spfile;
SHUTDOWN IMMEDIATE;
STARTUP;

-----------------------------------------------------------------
Disabling the Memory_max_target and Memory_target parameter methods
Note here that the official document says "unset", directly alter system set MEMORY_TARGET=0 Scope=spfile; Set it directly to ' 0 ' and hold the following error
Ora-00843:parameter not taking Memory_max_target to account
Ora-00849:sga_target 35433480192 cannot is set to more than Memory_max_target 0.
Ora-01078:failure in processing system parameters
By creating a Pfile.ora file, and then deleting the two parameter "Memory_target/memory_max_target" in the file. Then you can create SPFile.
-----------------------------------------------------------------

1.4, calculate the value of Vm.nr_hugepages
Computes the value of vm.nr_hugepages using script hugepages_settings.sh provided by Oracle
Ensure that all Oracle instances are started and ASM is started (if present) before executing the script
If the hugepages configuration is feasible, he will recommend a memory size, if not feasible, the error
$./hugepages_settings.sh
...
Recommended setting:vm.nr_hugepages = 1496 (sga_m/4m + 3)

1.5. Edit/etc/sysctl.conf to set vm.nr_hugepages parameters
$ sysctl-w vm.nr_hugepages = 1496
$ sysctl-p

1.6. Stop all instance and restart the server
All of the above steps have been dynamically modified, but the allocation for hugepages requires a restart of the server to take effect.

1.7. Verify the value of the match
The value of the hugepages correlation parameter changes dynamically as the instance on the current server stops and starts
Typically, the value of hugepages_free should be less than the value of Hugepages_total, and the HUGEPAGES_RSVD value should be a non-0 value when Hugepages is used.
$ grep huge/proc/meminfo
hugepages_total:131
Hugepages_free:20
Hugepages_rsvd:20
hugepagesize:2048 KB

In the following scenario, when only one instance of the server is closed, the value of HUGEPAGES_RSVD is zero. and Hugepages_free equals Hugepages_total.
$ grep huge/proc/meminfo
hugepages_total:131
hugepages_free:131
hugepages_rsvd:0
hugepagesize:2048 KB

Second, the use of hugepages precautions
The following three scenarios should be reconfigured Hugepages
A, increase or decrease of physical memory
B. Add or remove instance on the current server
C, instance the size of the SGA increases or decreases
If you fail to adjust the hugepages, the following problem may be raised
A, database performance underground
B. Out of memory or excessive use of swap space
C. DB instance cannot be started
D. Critical system service failure

Common fault handling of hugepages characteristics
Symptom A:
System is running out of memory or swapping
Possible Cause:
Not enough hugepages to cover the SGA (s) and therefore the area reserved for hugepages is wasted where Sgas is allocated through regular pages.
Troubleshooting Action:
Review your hugepages configuration to make sure the all SGA (s) is covered.

Symptom B:
Databases fail to start
Possible Cause:
Memlock limits is not set properly
Troubleshooting Action:
Make sure the settings on limits.conf apply to database owner account.

Symptom C:
One of the database fail to start while another are up
Possible Cause:
The SGA of the specific database could not find available hugepages and remaining RAM are not enough.
Troubleshooting Action:
Make sure, the RAM and Hugepages is enough to cover all your database Sgas

Symptom D:
Cluster ready Services (CRS) fail-to-start
Possible Cause:
Hugepages configured Too large (maybe larger than installed RAM)
Troubleshooting Action:
Make sure the total SGA are less than the installed RAM and Re-calculate hugepages.

Symptom E:
Hugepages_total = Hugepages_free
Possible Cause:
Hugepages is not used at all. No database instances is up or using AMM.
Troubleshooting Action:
Disable AMM and make sure, the database instances is up.

Symptom F:
Database started successfully and the performance is slow
Possible Cause:
The SGA of the specific database could not find available hugepages and therefore the SGA are handled by regular pages, whi CH leads to slow performance
Troubleshooting Action:
Make sure, the hugepages is many enough to cover all your database Sgas
Reference: [ID 361468.1]

Iv. How do I control whether the database SGA uses hugepages? In the previous version of the
11.2.0.2, database's SGA can only choose to use hugepages or not hugepages at all.
11.2.0.2 and later versions, Oracle added a new parameter, "Use_large_pages", to manage how the database uses Hugepages. The
Use_large_pages parameter has three values: "True" (default), "only", "false" and "Auto" (since 11.2.0.3 patchset).
1. The default value is "true" now, and if the system is set to Hugepages, the SGA will take precedence over hugepages and how much to use.
11.2.0.2 If there is not enough hugepages, the SGA will not use hugepages. This causes the ORA-4030 error because hugepages has been allocated from physical memory, but the SGA does not use it, but uses other parts of the memory. Insufficient memory resources
but in the 11.2.0.3 version This usage policy has been changed, the SGA can be part of the use of hugepages, and the remainder uses small pages. In this way, the SGA will have limited use of hugepages, and then use regular sized pages after hugepages is exhausted.
2. If set to "false", the SGA will not use Hugepages
3. If set to "only" if the hugepages size is insufficient, the DB instance cannot be started (preventing a memory overflow).
4. After version 11.2.0.3, you can set it to "Auto". This option triggers the oradism process to reconfigure the Linux kernel to increase the number of hugepages. The oradism needs to be given the appropriate permissions, as follows
-rwsr-x---1 root <oracle group>
It will not change/etc/ The hugepages value in the sysctl.conf file, and when the OS restarts, the system reverts to the Hugepages value configured in/etc/sysctl.conf.

Five, matters needing attention
A, Hugepage uses shared memory, is dynamically allocated and retained during operating system startup, because they are not replaced.
b, due to the characteristics of not being replaced, in the use of hugepage memory can not be used by other processes. Therefore, it is reasonable to set this value to avoid wasting memory.
C, for servers that use only Oracle, set the Hugepage to the SGA (all instance SGA) size.
D, if you increase hugepage or add physical memory or if the current server adds new instance and the SGA changes, you should reset the required Hugepage.

Oracle's Configuration Hugepages memory