OID 12c Memory Leak in Oidmon When Using Database Network Encryption Settings in DB Sqlnet.ora File (Doc ID 2472740.1)

Last updated on AUGUST 30, 2023

Applies to:

Symptoms

1.  OIDMON process is constantly growing in memory size.

Example:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 3623 oracle 20 0 5793660 133628 6608 S 5,9 1,1 162:36.25 oidldapd
 3284 oracle 20 0 113172 248 244 S 0,0 0,0 0:00.00 startNodeManage
 3290 oracle 20 0 113308 236 236 S 0,0 0,0 0:00.01 startNodeManage
 3398 oracle 20 0 3327848 147808 4544 S 0,0 1,2 2544:55 java
 3616 oracle 20 0 12,1g 9,3g 45172 S 0,0 80,3 45:25.69 oidmon   <<<<< oidmon consuming excessive Memory.
 3620 oracle 20 0 2072188 300 220 S 0,0 0,0 7:51.05 oiddispd
 3634 oracle 20 0 5793664 130692 3248 S 0,0 1,1 162:39.15 oidldapd
 3636 oracle 20 0 5793660 130492 2880 S 0,0 1,1 162:17.43 oidldapd
 3638 oracle 20 0 5794104 462468 2680 S 0,0 3,8 162:13.52 oidldapd

This occurs when network encryption is enabled in the sqlnet.ora on Database (DB) server side.

If DB network encryption is disabled, the oidmon processes does not grow in memory size.

2.  dmesg shows oidmon is getting killed due to an "Out of Memory" error.

From dmesg command output:

...
[3709210.544319] Out of memory: Kill process <PID> (oidmon) score 195 or
sacrifice child
[3709210.544923] Killed process <PID> (oidmon) total-vm:5028900kB,
anon-rss:2761968kB, file-rss:40444kB
[3835967.084962] java invoked oom-killer: gfp_mask=0x201da, order=0,
oom_score_adj=0

SNIP-IT

[3835967.087369] Call Trace:
[3835967.087369]  [<ffffffff8174ac49>] dump_stack+0x63/0x81
[3835967.087369]  [<ffffffff81746c0d>] dump_header+0x8e/0x221
[3835967.087369]  [<ffffffff817530b0>] ? _raw_spin_unlock_bh+0x30/0x70
[3835967.087369]  [<ffffffff8119f4ee>] oom_kill_process+0x1ee/0x3e0
[3835967.087369]  [<ffffffff8119fa76>] __out_of_memory+0x336/0x530
[3835967.087369]  [<ffffffff8119fe0b>] out_of_memory+0x5b/0x80
[3835967.087369]  [<ffffffff811a599f>] __alloc_pages_nodemask+0x9ef/0xa10
[3835967.087369]  [<ffffffff8174e28a>] ? __schedule+0x24a/0x850
[3835967.087369]  [<ffffffff811eee01>] alloc_pages_current+0x91/0x100
[3835967.087369]  [<ffffffff8119b90f>] __page_cache_alloc+0x9f/0xc0
[3835967.087369]  [<ffffffff8119de1e>] filemap_fault+0x1ae/0x440
[3835967.087369]  [<ffffffffa041d0ba>] ext4_filemap_fault+0x3a/0x60 [ext4]
[3835967.087369]  [<ffffffff811c9762>] __do_fault+0x52/0xc0
[3835967.087369]  [<ffffffff811ccb48>] handle_pte_fault+0x858/0x1700
[3835967.087369]  [<ffffffff811ceef3>] handle_mm_fault+0x203/0x4d0
[3835967.087369]  [<ffffffff810714cc>] __do_page_fault+0x1ac/0x460
[3835967.087369]  [<ffffffff817593fa>] ? page_fault+0xda/0x120
[3835967.087369]  [<ffffffff810717b0>] do_page_fault+0x30/0x90
[3835967.087369]  [<ffffffff817593c2>] ? page_fault+0xa2/0x120
[3835967.087369]  [<ffffffff817593bb>] ? page_fault+0x9b/0x120
[3835967.087369]  [<ffffffff817593b4>] ? page_fault+0x94/0x120
[3835967.087369]  [<ffffffff8175942f>] page_fault+0x10f/0x120
[3835967.106837] Mem-Info:

Changes

Cause

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