11gR2/Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (文档 I

11gR2/Aix - Dedicated Server Processes Have Large Usla Heap Segment Compared To Older Versions (文档 ID 1260095.1)

转到底部

---

In this Document

Symptoms

Changes

Cause

Solution

References

---

Applies to:

Oracle Database - Enterprise Edition - Version 11.2.0.1 and later
IBM AIX on POWER Systems (64-bit)

Symptoms

Dedicated server processes using significantly more memory on 11gR2 compared to previous versions (9i, 10g, 11g).

Using svmon to monitor process memory segment after initial DB connection, You can observe that typical USLA heap size jumped from ~0.4M in 10g to 7.0M in 11gR2.

svmon -P PID - where PID is an Oracle process id

Oracle Release -> (work USLA heap times 4k pages size)

11.2.0.1.0 -> 7M bytes
11.1.0.7.0 -> 60KB
10.2.0.4.0 -> 420KB

Slow system performance for larger footprint of all oracle server process. If physical memory is fully used, the could terminate an Oracle instance via terminating a PMON process.

 

Changes

Upgraded to 11gR2

Cause

In 11gR2, the Oracle server process (oracle binary) is linked with an additional linker options:-bexpful and -brtllib

The -bexpfull and -brtllib linker options were added to implement the Oracle hot patching functionality

In the previous releases of Oracle 11gR1, 10g and 9i, the -bexpful and -brtllib ld options are not used.

USLA heap usage from an "svmon -p of an Oracle server process" would be around 1800 4KB pages (~7MB) and this USLA heap is process private. This is needed for Oracle on-line patching: a new functionality implemented in 11gR2. With this feature, global symbols in the Oracle binary are saved in USLA heap for resolving the new object files in the shared libraries included in a patch.

Oracle has created fix in
Bug 10190759 - PROCESSES CONSUMING ADDITIONAL MEMORY DUE TO 'USLA HEAP'

Solution

Please see latest information published by IBM:

Technical Note IBM Oracle International Competency Center (IOICC)

The IBM and Oracle recommended resolution is that customers upgrade to AIX 6.1 TL09 or AIX 7.1 TL03 (use latest SP), and then apply the Oracle patch for database 11.2.0.2 and 11.2.0.3 that can be found by searching My Oracle Support (MOS) for bug number 13443029 (please note that a userid and password are required to access MOS).  This patch relinks Oracle with the current TL’s, reducing per-process memory consumption for "USLA heap" segment.  When upgrading your environment it is recommended to use AIX 6.1 TL09 SP03 (minimum TL07 SP10) or AIX 7.1 TL03 SP03 (minimum TL01 SP06) or higher.  If AIX 6.1 TL09 SP03 or AIX 7.1 TL03 SP03 or higher is not used, you need to ensure that the following APAR is appropriately installed for your OS level to resolve a linker error that will occur with Oracle installation or with the relinking. For example:

AIX 6.1 TL-07 APAR IV09580, IV28319, and IV20880

http://www-01.ibm.com/support/docview.wss?uid=isg1IV09580

http://www-01.ibm.com/support/docview.wss?uid=isg1IV28319

http://www-01.ibm.com/support/docview.wss?uid=isg1IV20880

click on "obtain the fix for this APAR;" choose 6100-07

 

AIX 7.1 TL-01 APAR IV09541, IV28925, and IV21116

http://www-01.ibm.com/support/docview.wss?uid=isg1IV09541

http://www-01.ibm.com/support/docview.wss?uid=isg1IV28925

http://www-01.ibm.com/support/docview.wss?uid=isg1IV21116

click on "obtain the fix for this APAR;” choose 7100-01

 

Also, IBM recommends that customers, who have multiple Oracle 11gR2 database or ASM installed on the same LPAR and the installed areas are patched or going to be patched with Oracle’s USLA heap patch, apply APAR IV20880 on AIX 6.1 TL-07 or APAR IV21116 on AIX 7.1 TL-01 to resolve system or application crash or hang that may occur in certain conditions.  

If customer cannot upgrade to AIX 6.1 TL09 or AIX 7.1 TL03, apply the Oracle patch that can be found by searching My Oracle Support (MOS) for bug number 10190759. This Oracle patch also relinks the binary to reduce the memory footprint of Oracle processes; however it has the disadvantage of disabling Oracle's online patching mechanism.

---------------------------------------------------------------------------------------------------------------------
There is also a workaround: linking the Oracle 11gR2 binary without -bexpful and -brtllib option.
These are the steps:

Please also note that the environment variable SHARED_SYMTAB must be o be set to 'Y'. When set to 'N' it results in the shared symbol table run loader feature being disabled for any binaries running in that environment (including Oracle).
This causes the processes to continue to use additional memory for the Work USLA Heap

Details are available in Bug 17909393.

- create under $ORACLE_HOME/rdbms/lib a file called opi.exp which will contain just this line :

opimai_real

- change the file permission to 775 (-rwxrwxr-x) :

chmod 775 opi.exp

- do a backup of original en_rdbms.mk under $ORACLE_HOME/rdbms/lib

cp -p env_rdbms.mk env_rdbms.mk_ORIGINAL

- edit env_rdbms.mk under $ORACLE_HOME/rdbms/lib
- add in the list of variables :

OPI_EXP=$(RDBMSLIB)/opi.exp

- change the line 3448 from

ORACLE_LINKLINE+=$(AIO_NWAIT_TIMEOUT_EXP) -bE:$(ODM_EXP) -bE:$(LIBCOREJAVA_EXP) -bpT:0x100000000 -bpD:0x110000000 -bforceimprw -brtllib -bexpfull

to

ORACLE_LINKLINE+=$(AIO_NWAIT_TIMEOUT_EXP) -bE:$(ODM_EXP) -bE:$(LIBCOREJAVA_EXP) -bpT:0x100000000 -bpD:0x110000000 -bforceimprw -bE:$(OPI_EXP)

- run the command: relink all



NOTE:
Customer suggested alternative for 11.2.0.3 is to edit env_rdbms.mk line 3523 to:

ORACLE_LINKLINE+= -bE:$(ODM_EXP) -bE:$(LIBCOREJAVA_EXP) $(PL_ADDR_OPTS) -bE:$(OPI_EXP)

 

NOTE:
if you don't use the opi.exp steps documented above, at instance startup you will get:

   ERROR:
   ORA-12547: TNS:lost contact

 

Apply Patch:10190759 or relinking oracle without -bexpful and -brtllib options it will disable the on-line patching functionality.

 

References

BUG:10211065 - MEMORY FOOTPRINT FOR DEDICATED SERVER PROCESSES MORE THAN DOUBLED AFTER 11G UGP
BUG:10190759 - PROCESSES CONSUMING ADDITIONAL MEMORY DUE TO 'USLA HEAP'
BUG:9796810 - 11G SERVER PROCESSES CONSUMING MUCH MORE MEMORY THAT 10G OR 9I

BUG:18755510 - PROCESSES CONSUMING ADDITIONAL MEMORY DUE TO 'USLA HEAP'