全部博文（50）
分类： Oracle
2014-08-24 15:56:49
In this Document
Purpose
Scope
HugePages on Oracle Linux 64-bit
Introduction
Why Do You Need HugePages?
How to Configure
Check and Validate the Configuration
Troubleshooting
Known Problems and Limitations
Further Reading
References
Linux OS - Version: Enterprise Linux 4.0 to Oracle Linux 6.0 with Unbreakable Enterprise Kernel [2.6.32] - Release: RHEL4 to OL6
Oracle Server - Enterprise Edition - Version: 9.2.0.1 and later [Release: 9.2 and later]
Linux x86-64
Oracle Linux
Red Hat Enterprise Linux (RHEL)
SUSE Linux Enterprise Server (SLES)
This document aims to provide.
Information in this document is useful for Linux system
administrators and Oracle database administrators working with system
administrators.
This document covers information about Linux HugePages for 64-bit
architectures. For more generic and uses on 32-bit and for references
please see Document 361323.1
The configuration steps provided here is primarily for Oracle Linux.
Still the same concepts and configurations should apply to other Linux
distributions.
HugePages is a feature of the Linux kernel which allows larger pages to manage memory as the alternative to the small 4KB pagesize. For a detailed introduction, see Document 361323.1.
HugePages is crucial for faster Oracle database performance on Linux if you have a large RAM and SGA. If your combined database SGAs is large (like more than 8GB, can even be important for smaller), you will need HugePages configured. Note that the size of the SGA matters. Advantages of HugePages are:
The configuration steps below will guide you to do a persistent system configuration where you would need to do a complete reboot of the system. Please plan your operations accordingly:
Step 1: Have the memlock user limit set in /etc/security/limits.conf file. Set the value (in KB) slightly smaller than installed RAM. e.g. If you have 64GB RAM installed, you may set:
* soft memlock * hard memlock 60397977
There is no harm in setting this value large than your SGA requirements.
The parameters will be set by default on:
@ See also Document 1284261.1 for Exadata
Step 2: Re-logon to the Oracle product owner account (e.g. 'oracle') and check the memlock limit
$ ulimit -l
Step 3: If you have Oracle Database
11g or later, the default database created uses the Automatic Memory
Management (AMM) feature which is incompatible with HugePages. Disable
AMM before proceeding. To disable, set the initialization
parameters MEMORY_TARGET and MEMORY_MAX_TARGET to 0 (zero). Please see Document 749851.1 for further information.
Step 4: Make sure that all your database instances are up (including ASM instances) as they would run on production. Use the script hugepages_settings.sh in Document 401749.1 to calculate the recommended value for the vm.nr_hugepages kernel parameter. e.g.:
$
Note: You can also calculate a proper value for the
parameter yourself but that is not advised if you do not have extensive
experience with HugePages and concepts.
Step 5: Edit the file /etc/sysctl.conf and set the vm.nr_hugepages parameter there:
...
...
This will make the parameter to be set properly with each reboot.
Step 6: Stop all the database instances and reboot the server
(Although settings could have been done dynamically they would not be
effective to the extent we require before a reboot. The best practice is
to do a persistent system configuration and perform a reboot to
complete the configuration as presented through the
steps above)
What If the Database / SGA Configurations Change?
The performed configuration is basically based on the RAM installed and combined size of SGA of database instances you are running. Based on that when:
After the system is rebooted, make sure that your database instances (including the ASM instances) are started. Automatic startup via OS configuration or CRS, or manual startup (whichever method you use) should have been performed. Check the HugePages state from /proc/meminfo. e.g.:
The values in the output will vary. To make sure that the configuration is valid, the HugePages_Free value should be smaller than HugePages_Total and there should be some HugePages_Rsvd. The sum of Hugepages_Free and HugePages_Rsvd may be smaller than your total combined SGA as instances allocate pages dynamically and proactively as needed.
Some of the common problems and how to troubleshoot them are listed in the following table:
| Symptom | Possible Cause | Troubleshooting Action |
|---|---|---|
| System is running out of memory or swapping | Not enough HugePages to cover the SGA(s) and therefore the area reserved for HugePages are wasted where SGAs are allocated through regular pages. |
Review your HugePages configuration to make sure that all SGA(s) are covered. |
| Databases fail to start | memlock limits are not set properly | Make sure the settings in limits.conf apply to database owner account. |
| One of the database fail to start while another is up | The SGA of the specific database could not find available HugePages and remaining RAM is not enough. | Make sure that the RAM and HugePages are enough to cover all your database SGAs |
| Cluster Ready Services (CRS) fail to start | HugePages configured too large (maybe larger than installed RAM) | Make sure the total SGA is less than the installed RAM and re-calculate HugePages. |
| HugePages_Total = HugePages_Free | HugePages are not used at all. No database instances are up or using AMM. | Disable AMM and make sure that the database instances are up. |
| Database started successfully and the performance is slow | The SGA of the specific database could not find available HugePages and therefore the SGA is handled by regular pages, which leads to slow performance | Make sure that the HugePages are many enough to cover all your database SGAs |
Below are some of the known and related problems and limitations related to the HugePages feature:
To be able to do advanced / manual configurations with HugePages you need to understand the implementation and theory behind the concept. You may read the following for further information:
