My Oracle Support Banner

High Memory Usage in GIPC Code (Doc ID 1338981.1)

Last updated on FEBRUARY 03, 2019

Applies to:

Oracle Database - Enterprise Edition - Version and later
Information in this document applies to any platform.


11gR2 Grid Infrastructure GIPC code uses high memory, symptom is one or more processes (octssd.bin, crsd.bin etc) allocates huge amount of memory over time, exhausts memory and swap space eventually resulting in node eviction or other stability issue.

With OS "top" or other memory monitoring tool, we can see huge virtual memory is allocated and increasing over time:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                     
7242 oracle    18   0  308g 953m  14m S 83.2  0.7 166:28.72 octssd.bin

In above example, 308GB of virtual memory is allocated.

Clusterware trace may have the following:

[GIPCXCPT][1100249408] gipcDestroyPtrF [gipcEndpointProcess : gipcEndpoint.c : 259]: EXCEPTION[ ret gipcretInvalidObject (3) ]  failure to destroy obj 0x7fabe412acb0 [000000000006951c]  { gipcReceiveRequest : peerName 'ipc', data 0x7fabe40ce1c8, len 10240, olen 672, off 0, parentEndp 0x8b5040, ret gipcretSuccess (0), objFlags 0x0, reqFlags 0xac }, flags 0x0
[GIPCXCPT][1100249408] gipcObjectCheckF [gipcDestroyPtrF : gipcInternal.c : 2138]: invalid object magic, obj 0xb2f908, magic èè/è, realMagic gipcObjs (63706967 736a624f), type gipcObj ect, ret gipcretInvalidObject (3)

On Windows, handle leak can be observed


To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

In this Document

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.