oracle不使用大页内存(文档 ID 803238.1)

APPLIES TO:

Oracle Database - Enterprise Edition - Version 10.2.0.4 to 11.1.0.7 [Release 10.2 to 11.1]
Information in this document applies to any platform.
***Checked for Relevance 26-AUG-2014***

SYMPTOMS

-- Problem Statement:
Customer states that ORACLE IS NOT UTILIZING HUGEPAGES.

Kernel parameter memlock was checked and set according to:
Note 361468.1 - HugePages on Oracle Linux 64-bit

CAUSE

Causes numbered below:

1)
The total size of huge pages of 16384 * 2048 * 1024 = 34359738368 is less than the shared memory
segment requested in the call of shmget.

The value reported in the shmget is a small overhead of 2M above the sga_max_size (34359738368):
(You will need strace or a similar too to see the shmget call.  The next cause below shows more detail on this.)

shmget (34361835520) - sga_max_size (34359738368)) = 2097152 bytes = 2048k = 2M


2) Another potential cause is that NUMA is enabled, which is the default on 10.2.0.4 .

You can see evidence of this by the strace output.  You may use other tracing tools on other platforms. (ie...truss, tusc)  The numbers below DO NOT coincide with the figures above, but are yet another example of what may cause HUGEPAGES to not be utilized by Oracle.

To troubleshoot this method perform your database needs to be shutdown so that a new "startup" can be issued and traced.

oracle@myhost ~]>strace -f -o output.txt sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Thu Jul 30 16:58:27 2009

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area  285212672 bytes
Fixed Size                  1267044 bytes
Variable Size             142609052 bytes
Database Buffers          134217728 bytes
Redo Buffers                7118848 bytes
Database mounted.
Database opened.
SQL>

Then open the output.txt and search for "startup".  You should then see a output below here indicating shmget calls:

17283 shmget(2256778204, 4096, 0) = -1 ENOENT (No such file or directory)
17283 shmget(2256778204, 0, 0) = -1 ENOENT (No such file or directory)
17283 shmget(2256778205, 4096, 0) = -1 ENOENT (No such file or directory)
17283 shmget(2256778205, 0, 0) = -1 ENOENT (No such file or directory)
17283 shmget(2256778206, 4096, 0) = -1 ENOENT (No such file or directory)
17283 shmget(2256778206, 0, 0) = -1 ENOENT (No such file or directory)
17283 shmget(2256778207, 4096, 0) = -1 ENOENT (No such file or directory)
17283 shmget(2256778207, 0, 0) = -1 ENOENT (No such file or directory)

You'll notice we see 8 calls to shmget (for almost equally sized blocks) vs 1 for the entire block. The allocation also exceeds your calculations for the number of hugepages at this point resulting in a failed startup.  (In the case here the customer was attempting to configure an SGA of 11GB, but we see much more being allocated by the shmget calls.)

NUMA - the command "numactl --show" will show resource pools on Linux. You may check with your Systems administrator for O/S level commands on other platforms.

Patch 8199533 is available for several platforms and versions of the Oracle Database server.
The patch will disable the default enabled behavior.
Note:

The issue does not occur on 10.2.0.5 as it already has the fix for Bug 8199533 ;hence NUMA is disabled by default.

Other NUMA related issues are documented in: 
Note 759565.1 - Oracle NUMA usage recommendation


- OR -

3)
A parameter is set blocking the allocation:

_db_block_cache_protect is set to TRUE
This parameter SHOULD NOT be set unless specifically advised by Support or DEV.

Linux:
mprotect will work on Linux, however, be aware of the following bug for 64-bit systems:

Unpublished Bug 6955340 - _db_block_cache_protect does not work in linux x64
Fixed in 10.2.0.4, 11.1.0.7 and 11.2

SOLUTION

-- To implement the solution, please execute the following steps referencing the Cause Number above:

1)
Increase the number of huge pages from 16384 to 16400 and increase the memlock to the new size of 16400 * 2048.  (The numbers here were specific to this example.  The calculations for the correct value may need to be adjusted and bumped up to allocate correctly.)

2)
If the troubleshooting steps in the Cause 2 (i.e. using strace or another process tracing utility) show you that NUMA is causing this, apply Patch 8199533

3)
If the parameter _db_block_cache_protect is set to TRUE and you are not under direct advisement from  Support or DEV please disable, i.e. set it to FALSE.