Skip to Main Content
  • Questions
  • ORA-04030 - Init "_realfree_heap_pagesize_hint" VS kernel parameters vm.max_map_count

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Mirsade.

Asked: October 03, 2016 - 12:32 pm UTC

Last updated: August 07, 2024 - 3:37 am UTC

Version: 11.2.0.4

Viewed 10K+ times! This question is

You Asked

ORA-04030, oracle init "_realfree_heap_pagesize_hint" VS kernel parameters vm.max_map_count

HI,

We are facing several database crash due to memory leak.
We would like now to limit oracle memory used by a single process.
As you know there is not limit for PGA on Oracle 11g.
But seems that we can limit process memory using headen parameters.
According my understanding "_realfree_heap_pagesize_hint" is by default set to 16 GB [ number of max process allowed by oracle is 65536,
page size is limited to 256KB , so a process can consumme ( 65536 X 256 KB ) = 16 GB ]
On your set tu "_realfree_heap_pagesize_hint = 8M"

Reading, oracle support seems that vm.max_map_count should be aligned with "_realfree_heap_pagesize_hint".
But really can't undertstand why ?
vm.max_map_count define number of memory bloc that can be used by a single process, bloc can be 64KB, 256 KB ... or a mixe of diifferent bloc size.

I need Tom view's on this point.

How should we size this 2 parameters ?

Is there any specific recommandation regarding process memory limit ?^

Thanks in advance for your help.


and Connor said...

Well...for starters, that advice is for when you PGA is hitting a 4G limit within PLSQL execution. The first thing I'd be asking is - what coding approach was taken to have a plsql block need 4G of private memory. Because if something needs 4G, then who is to say that one day it wont need 10G or 50G or 100G and the problem simply comes back no matter what you do.

If you are referring to MOS note 1325100.1, then I see no mention where it says they need to be aligned, it just says they both need to be set to an appropriate value.

But given the choice of setting OS and hidden parameters to allow a process to consume more than 4G of PGA...and re-thinking the process, I'd choose the latter

Rating

  (5 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

ORA-04030 when the private memory hits 32GB

Morgan, July 30, 2024 - 3:53 am UTC

Greetings!
This is on Exadata X9M system (DB node has 2TB memory total and 1TB free memory available, 600GB of PGA set. Database is on 19.18.

We are getting ORA-04030 error when the private memory hits 32GB. Appreciate if you can shed some insights on this.

1) Just wondering, if there is PL/SQL memory allocation limit with bulk collection ?

2) Even though we have free memory available, just trying to figure out why Oracle is not able to grow more than 32GB limit ?

Can you please suggest if we need to adjust any of the OS/DB settings below or bulk collect with LIMIT in the code has to be changed ?

Setting in the DB:

SQL> show parameter pga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size                        big integer 20G
pga_aggregate_limit                  big integer 0
pga_aggregate_target                 big integer 600G

Parameter                      Default Value        Session Value                  Instance Value                 IS_SESSION_MODIFIABL IS_SYSTEM_MODIFIABLE
------------------------------ -------------------- ------------------------------ ------------------------------ -------------------- --------------------
_realfree_heap_pagesize        TRUE                 65536                          65536                          FALSE                FALSE
_use_realfree_heap             TRUE                 TRUE                           TRUE                           FALSE                IMMEDIATE

-- more details follow from the trace --

PRIVATE HEAP SUMMARY DUMP
32 GB total: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 32 GB limit reached
32 GB commented, 1910 KB permanent
1539 KB free (0 KB in empty extents),
32 GB, 4 heaps: "koh-kghu call " 1241 KB free held



ORA-04030: out of process memory when trying to allocate 169040 bytes (pga heap,kgh stack)
ORA-04030: out of process memory when trying to allocate 16336 bytes (koh-kghu call ,pmuccst: adt/record)

========= Dump for incident 1292153 (ORA 4030) ========
----- Beginning of Customized Incident Dump(s) -----
=======================================
TOP 10 MEMORY USES FOR THIS PROCESS
---------------------------------------
100% 32 GB, 2088675 chunks: "pmuccst: adt/record " PL/SQL
koh-kghu call ds=0x7f794779e250 dsprt=0x7f794ee10220
0% 93 MB, 32795 chunks: "free memory " PL/SQL
koh-kghu call ds=0x7f794779e250 dsprt=0x7f794ee10220
0% 1312 KB, 1169 chunks: "free memory "
pga heap ds=0x7f794ee10220 dsprt=(nil)



-------------------------
Top 10 processes:
-------------------------
(percentage is of 58 GB total allocated memory)
55% ospid 258173 ( ): 32 GB used, 32 GB alloc <= CURRENT PROC
1% ospid 59134 (ARC1): 97 MB used, 703 MB alloc, 601 MB freeable
1% ospid 258396_258418 (LMSH): 592 MB used, 600 MB alloc
1% ospid 258396_258417 (LMSF): 567 MB used, 568 MB alloc


ospid 258173 ( ): 32 GB used, 32 GB alloc
------------------------------------

current SQL:
select AMT_OUTSTANDG_HIST_BI_OBJ(INSTR_ID,CHANGE_DATE,CHANGE_REASON,CHILD_INSTR_ID,TRANCHE_INSTR_ID,AMOUNT_OUTSTANDING,AMOUNT_OUTSTANDING_DECIMAL,AMOUNT_OUTSTANDING_RATIO_DATE,CHANGE_DIFFERENCE,CHANGE_DIFFERENCE_DECIMAL,CHANGE_SOURCE,MARKERS_QUALIFIERS,TRANCHE_AMOUNT,TRANCHE_DATE,TRANCHE_ISSUE_PRICE,recorded_date_start,recorded_date_end,EFFECTIVE_DATE_START,effective_date_end,LOADED_BY)
                    bulk collect into msg_intraday_table from (
                          select level, CONNECT_BY_ISLEAF AS LEAF,rn,INSTR_ID,CHANGE_DATE,CHANGE_REASON,CHILD_INSTR_ID,TRANCHE_INSTR_ID,AMOUNT_OUTSTANDING,AMOUNT_OUTSTANDING_DECIMAL,AMOUNT_OUTSTANDING_RATIO_DATE,CHANGE_DIFFERENCE,CHANGE_DIFFERENCE_DECIMAL,CHANGE_SOURCE,MARKERS_QUALIFIERS,TRANCHE_AMOUNT,TRANCHE_DATE,TRANCHE_ISSUE_PRICE,LOADED_BY,
                                 prev_amount_outstanding, recorded_date_start, recorded_date_end,
                                 --CHANGE_DATE + interval '1' minute * (level-1)  as effective_date_start, CHANGE_DATE + interval '1' minute * level  as effective_date_end
                                 case when rn = 1 then CHANGE_DATE else CHANGE_DATE + interval '1' minute * (rn-1) end as effective_date_start,
                                 case when rn = 1 then CHANGE_DATE else CHANGE_DATE + interval '1' minute * rn end as effective_date_end
                          from (
                                   select
                                       ROW_NUMBER() OVER(PARTITION BY INSTR_ID, change_date order by change_date, amount_outstanding desc) as rn,
                                       INSTR_ID, CHANGE_DATE,CHANGE_REASON,CHILD_INSTR_ID,TRANCHE_INSTR_ID,AMOUNT_OUTSTANDING,AMOUNT_OUTSTANDING_DECIMAL,AMOUNT_OUTSTANDING_RATIO_DATE,CHANGE_DIFFERENCE,CHANGE_DIFFERENCE_DECIMAL,CHANGE_SOURCE,MARKERS_QUALIFIERS,TRANCHE_AMOUNT,TRANCHE_DATE,TRANCHE_ISSUE_PRICE,LOADED_BY,
                                       case when change_difference is null then amount_outstanding else amount_outstanding-change_difference end as prev_amount_outstanding,
                                       sys_extract_utc(SYSTIMESTAMP) as recorded_date_start, v_end as recorded_date_end
                                   from table (object_collection)
                               )
                          where level != CONNECT_BY_ISLEAF
                          CONNECT BY NOCYCLE PRIOR amount_outstanding = prev_amount_outstanding and prior INSTR_ID = INSTR_ID --and prior CHANGE_DATE = CHANGE_DATE
                          START WITH prev_amount_outstanding = 0);


Connor McDonald
July 30, 2024 - 6:13 am UTC

I'm checking with the Exadata team on this and will report back

ORA-04030

Morgan, July 30, 2024 - 3:13 pm UTC

Thanks Connor!
Connor McDonald
August 06, 2024 - 12:31 am UTC

glad to help

ORA-04030

Morgan, August 05, 2024 - 3:02 pm UTC

Hello Connor,

Just checking if you got a chance to check with Exadata team.

Thanks you.
Connor McDonald
August 06, 2024 - 12:27 am UTC

Nothing firm, but I dug around a bit.

We used to have a 16G limit back in 11, which got raised to (I think) 64G in 12, which means there is definitely some activity on this over the year. (Its possible its been dropped to 32G).

I think the best way forward here would be to log an SR, because then you'll get a means to upload trace files etc for them to diagnose.

ORA-04030

Morgan, August 06, 2024 - 3:04 am UTC

Hi Connor,

Thanks for the info.

I did open the SR for this issue but there is not more useful info in the SR other than reference of this Oracle Doc ID 1325100.1 .

I am not able to match 32GB memory hard limit we hit following that note.

On our Exadata system and database:

$ more /proc/sys/vm/max_map_count
100000000
_realfree_heap_pagesize is set to 65536 (64K).



Basically, I asked this question in the SR but no answer on this.

1. We want to grow PGA memory up to available memory or PGA setting of 600GB.

What should be the recommended value for _realfree_heap_pagesize parameter ?



Below is the meminfo:

$ grep -i mem /proc/meminfo
MemTotal: 2112929132 kB
MemFree: 1144793356 kB
MemAvailable: 1164849136 kB
Shmem: 7598716 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB

2. Is there any upper limit on allocating max PGA memory into PL/SQL collection object. ?

Note that the query uses collection of collection.




-- as per Exadata team update on the SR-
The Default value in exadata is "100000000" from Exadata Software version 18.2 and above.

vm.max_map_count = 100000000

This parameter can be set any maximum value. We never recommend to change the default value for Exadata systems.

---

SR update: -
--
On database, set hidden parameter higher, for example:

_realfree_heap_pagesize_hint = 262144

In 12C, _realfree_heap_pagesize = 262144


The default realfree allocator pagesize is 64 KB, so 64K entries take up 4GB. With 256KB pages as specified above, the limit goes up to 16GB. Increasing both the OS map entries and pagesize would allow higher than 16GB.

No quantitative data available regarding performance for either setting. May want to test both settings to determine if either provides better performance.

See also the discussion below on Bug:14119856. If you want to allow a process greater than 16GB memory allocation you must also have this fix installed which allows up to 80G per process limit in addition to making changes to the above discussed map count and realfree page size. Otherwise, without this fix, the process will still be limited to 16GB.
--
Connor McDonald
August 07, 2024 - 3:37 am UTC

I must admit - If you're dragging 600G of data into a collection ... I'd be asking some questions about that approach to be honest

ORA-04030

Morgan, August 07, 2024 - 4:21 am UTC

Hi Connor,

I do not believe the collection object size is going to be really that big (600G), I basically wanted to grow the memory required for collection based on the available memory. I was looking for the answer how much max. memory collection can support. Thanks.