Windows 64bit使用内存大页

最新推荐文章于 2022-09-16 18:04:25 发布

congxinlan3332

最新推荐文章于 2022-09-16 18:04:25 发布

阅读量1.3k

点赞数 1

文章标签：数据库 c/c++

Using Large Memory Pages on 64-Bit Windows Systems [ID 422844.1]

		修改时间 30-JUN-2010 类型 BULLETIN 状态 PUBLISHED

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:

Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 11.1.0.6 - Release: 10.1 to 11.1
Microsoft Windows Itanium (64-bit)
Microsoft Windows x64 (64-bit)
Microsoft Windows Server 2003 (64-bit Itanium)Microsoft Windows Server 2003 (64-bit AMD64 and Intel EM64T)Microsoft Windows (64-bit) on Intel Itanium

Purpose

The purpose of this bulletin is to explain Large Page usage for the Oracle RDBMS on 64-Bit Windows systems, and to provide instructions on how to implement this feature.

Scope and Application

This bulletin is intended for Oracle DBA's and Windows Systems Administrators on 64-Bit Windows machines running Oracle databases. The purpose is to describe Oracle's implementation of Large pages on Windows, and explain how this can be configured.

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:

SOFTWARE\ORACLE\KEY_OraDb10g_home1

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

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDb10g_home1

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:

Starting ORACLE instance (normal)
Thu Apr 12 15:56:55 2007
Large page enabled : 1
Thu Apr 12 15:56:55 2007
Large page size : 16777216
Large page request size : 16777216
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
...........
...........

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

Starting ORACLE instance (normal)
Wed Apr 11 17:06:24 2007
Large page enabled : 1
Wed Apr 11 17:06:24 2007
Large page size : 33554432
Large page request size : 33554432
Wed Apr 11 17:06:24 2007
Optimized NUMA large page alloction size : 33554432
Wed Apr 11 17:07:28 2007
Total Numa LP allocations : 000000019E000000
Req. Numa LP allocations : 00000000C4000000
Wed Apr 11 17:07:28 2007
Numa LP Alloc on node: 0 alloc:0000000050000000 req:0000000050000000
Wed Apr 11 17:07:28 2007
Numa LP Alloc on node: 1 alloc:0000000050000000 req:0000000050000000
Wed Apr 11 17:07:28 2007
Numa LP Alloc on node: 2 alloc:0000000024000000 req:0000000024000000
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
..........

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.

SQL> startup
ORA-27102: out of memory
OSD-00022: additional error information
O/S-Error: (OS 1450) Insufficient system resources exist to complete the requested service.

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:

ORA-00600: internal error code, arguments: [SKGMINVALID], [6], [0], [275516362422484992], [], [], [], []

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:

SQL> startup
ORA-27102: out of memory
OSD-00010: additional error information
O/S-Error: (OS 1300) Not all privileges referenced are assigned to the caller.

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.