Applies to:

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)

Purpose

This document aims to provide.

Basic configuration of HugePages on 64-bit Linux
Fundemental reasons to use HugePages on Linux
References to known problems
References to technical background on HugePages

Scope

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 on Oracle Linux 64-bit

Introduction

Document 361323.1.

Why Do You Need HugePages?

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:

No Page Table Lookups: Since the HugePages are not subject to replacement (despite regular pages), page table lookups are not required.
Better Overall Memory Performance: On virtual memory systems (any modern OS) each memory operation is actually two abstract memory operations. With HugePages, since there are less number of pages to work on, the possible bottleneck on page table access is clearly avoided.
No Swapping: We must avoid swapping to happen on Linux OS at all Document 1295478.1. HugePages are not swappable (whereas regular pages are). Therefore there is no page replacement mechanism overhead. HugePages are universally regarded as pinned.
No 'kswapd' Operations: kswapd will get very busy if there is a very large area to be paged (i.e. 13 million page table entries for 50GB memory) and will use an incredible amount of CPU resource. When HugePages are used, kswapd is not involved in managing them. See also Document 361670.1

There is a general misconception where the HugePages is a feature specific to 32-bit Linux. HugePages is a generic feature available to all word-sizes and architectures. Just that there are some specifics with 32-bit platforms. Please see Document 361323.1 for further references.

How to Configure

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:

There is no harm in setting this value large than your SGA requirements.

The parameters will be set by default on:

Oracle Linux with oracle-validated package (See Document 437743.1) installed.
Oracle Exadata DB compute nodes

@ See also Document 1284261.1 for Exadata

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:

...

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:

Check and Validate the Configuration

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.:

# grep HugePages /proc/meminfo
HugePages_Total:    1496
HugePages_Free:      485
HugePages_Rsvd:      446
HugePages_Surp:        0

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.

Troubleshooting

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

Known Problems and Limitations

Below are some of the known and related problems and limitations related to the HugePages feature:

Document 749851.1 HugePages and Oracle Database 11g Automatic Memory Management (AMM) on Linux
Document 829850.1 Hugepages Are Not Used by Database Buffer Cache
Document 803238.1 Oracle Not Utilizing Hugepages
Document 728063.1 Setup HugePages in an Guest Does Not Work with Oracle VM 2.1 or 2.1.1
Document 550443.1 HugePages Not Released On Oracle RDBMS Instance Shutdown with RHEL / EL 5 Update 1 (5.1)
Document 860350.1 /proc/meminfo Does Not Provide HugePages Information on Oracle Enterprise Linux (OEL5)

References

NOTE:361323.1 - HugePages on Linux: What It Is... and What It Is Not...
NOTE:361670.1 - Slow Performance with High CPU Usage on 64-bit Linux with Large SGA
NOTE:401749.1 - Shell Script. to Calculate Values Recommended Linux HugePages / HugeTLB Configuration
NOTE:749851.1 - HugePages and Oracle Database 11g Automatic Memory Management (AMM) on Linux

source:http://blog.csdn.net/orion61/article/details/6698510

ID 361468.1 HugePages on Oracle Linux 64-bit