Windows 64bit使用記憶體大頁

In this Document
  Purpose
  Scope and Application
  Using Large Memory Pages on 64-Bit Windows Systems
     How do I enable Large Page Support for my Oracle Instance?
     Verifying that Large Pages are Enabled for your Instance
     Facts About Large Pages on Windows:
      Large Page Size
     Known Issues
  References

Applies to:

Purpose

Scope and Application

Using Large Memory Pages on 64-Bit Windows Systems

What is Large Page support and why would I use it?

Large page support is a feature of Oracle Database 10g R1 and 10gR2.  It can provide a performance boost for memory-intensive database instances running on Windows Server 2003, by using larger memory pages than the OS default size of 4k. Specifically, when large page support is enabled, the CPUs in the system will be able to access the Oracle Database buffers in RAM more quickly, because instead of addressing the buffers in 4KB increments, the CPUs are told to use 2 MB page sizes or larger.  The default page size depends on the chipset, and the total amount of memory in the system.  This will be discussed later in this bulletin.

How do I enable Large Page Support for my Oracle Instance?

Large Page Support for an Oracle instance is enabled by setting a REG_SZ registry entry called ORA_LPENABLE, or ORA__LPENABLE to a value of 1 in the appropriate registry key for the Oracle installation.   Setting ORA_LPENABLE will enable Large Page support for ALL instances running out of that ORACLE_HOME.  This is generally not recommended, particularly if you are using ASM, because this setting would also enable Large Page support for the ASM instance.   Thus, it is recommended to use ORA__LPENABLE whenever this parameter is used.

To identify the appropriate key, first determine the ORACLE_HOME directory that your Oracle Instance is running from.   You can do this as follows:

1. Go to the services console by running services.msc
2. Identify the service for your instance.   In this example, we will use an instance name of TEST1, so we have a service called 'OracleServiceTEST1'
3.  Right-Click on the OracleServiceTEST1 service and choose 'Properties'.  On the 'General' tab there will be a line titled 'Path to Executable'.   This will be the path to the BIN directory of your ORACLE_HOME
4.  Next, using Windows Explorer, go to that ORACLE_HOME\bin directory and find a file called 'oracle.key'.   Open this file using a text editor such as Wordpad or Notepad.   
5.  This file will give you the registry key information for the key associated with that particular home.   The contents of the file will look something like this:

This key is actually under HKEY_LOCAL_MACHINE, so the full key path would be:

6.  Open the registry via regedit and navigate to the key identified in Step#5 above.  With the key for the database home highlighted, go to the Regedit Menu and choose Edit->New->String Value
7.  Give the key a name of ORA_TEST1_LPENABLE   (In our example, we are using a SIDNAME of TEST1, but you will substitute your sidname as appropriate.
8.  After creating the new value, double-click on it and set it to a value of 1 to enable Large Page Support for that instance.
9.  You will need to stop the OracleServiceTEST1 service, and restart it, in order for the change to take affect.  If the instance is running, it should be shutdown cleanly (via SQLPLUS, for example) before the service is stopped.
10.  Note that if this is a RAC system, and you want instances on all nodes to use Large Pages, then you will have to add the value to the registry key on all nodes.  You can stop/restart the OracleServices in a rolling fashion, in order to avoid a full outage.

Verifying that Large Pages are Enabled for your Instance

You can get verification that Large Pages are enabled for your instance by checking the alert log.  At startup of the instance, you should see entries such as the following in your alert log, before the parameter listing:

On NUMA architecture systems  (such as AMD x64 systems) you will see entries such as the following:

Facts About Large Pages on Windows:

When using Large Pages on Windows, bear in mind the following: 

Large Pages are used only for the SGA -  so components of the SGA such as shared_pool, large_pool, java_pool  and db_cache_size, etc, will take advantage of large pages.   Other memory allocations for Oracle such as pga and uga memory, thread stacks, and process code for oracle.exe will not use large pages.

Large Pages are locked in memory by default by the operating system, meaning once the memory is allocated, it cannot be paged out.   Therefore, using parameters such as PRE_PAGE_SGA and LOCK_SGA are not necessary when using Large Pages.

Large Pages are not counted in the Working Set, so when monitoring Working Set, this value will be much lower than without large pages enabled.   In Windows Task Manager, the Mem Usage column is equivalent to the Working Set, so monitoring Mem Usage in Task Manager will also show memory usage much lower than what you would see otherwise.

Because Large Pages are locked in memory, if the OracleService is started by an account other than the LocalSystem account (default)  then the user account which is starting the service must have the 'Lock Pages in Memory'  privilege. To grant this privilege, go to:

Start ->  Administrative Tools -> Local Securiy Policy
Under Security Settings, Choose Local Policies -> User Rights Assignments.

In the Right-Hand pane, find the 'Lock Pages in Memory'  privilege, and grant that privilege to the account that the OracleService logs on as.

No kernel changes are required to be made to enable Large Pages.  Large page Support exists by default on Windows 2003 Server operating systems.

 Large Page Size

The default Large Page Size varies, depending on your platform.  
On 64-Bit x64 Windows, the default Large Page Size is 2MB.  
On 64-Bit Itanium, the default Large Page Size is 16MB. 

@ Setting ORA_LPSIZE or ORA__LPSIZE 
 

Known Issues

1.  If the system has been up and running for a long time, then startup may take a very long time, due to clean up of fragmented memory.     Refer to Note 862690.1 for more information on this.   In some cases, the startup may fail with the following errors if memory is too fragmented.  

If this occurs, then you may need to reboot the system in order to clean up the fragmented memory.

2.  In addition, the startup may fail with an ORA-600[SKGMINVALID] error, such as:

Again, this may be due to fragmentation of memory.   Changing to a larger page size may also help eliminate the above error.  In the above cases, setting the ORA_LPENABLE registry parameter to 0 to disable large pages will also allow the instance to start.

3.  On AMD Systems, you may need to disable Numa support in order to get the instance to start with Large Pages.   See Note 759565.1 for options/patches for NUMA.

You  may also do this by setting the following registry parameter as a REG_SZ, in the same key as the ORA_LPENABLE:
_ENABLE_NUMA   - set the value to FALSE.

Also, in the init.ora, set the following parameter:
_ENABLE_NUMA_OPTIMIZATION = FALSE

4.  If the service is running as a user, then it needs lock pages in memory privileges.  Failure to grant this privilege will result in the following error:

To correct this, follow the steps listed earlier to grant the 'Lock Pages in Memory' privilege to the user, and then stop and restart the OracleService

5. With large pages, startup can sometimes be slow, as noted in Point#1 above.  This is due to high kernel CPU usage as the kernel is reclaiming pages to get contiguous large pages.  On RAC systems running Oracle Clusterware, in some cases this high CPU utilization in the kernel may prevent OCSSD or the Oracle Fence Driver from getting CPU time, thus causing Missed Check-ins with other nodes, or a perceived hang of the system.   In extreme cases, this can lead to a node eviciton.  This is more likely on systems with larger SGA's, that have been up and running for a long time, through multiple shutdowns/restarts of the database.   To avoid this, a clean boot of the system prior to restarting the database after the system has been up for an extended time will prevent the need to do much memory reclamation.  Again, Note 862690.1  has more information on this issue.

References