Skip to Main Content
  • Questions
  • SGA and background process memory allocation

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, John.

Asked: January 15, 2013 - 2:55 pm UTC

Last updated: March 16, 2022 - 3:36 am UTC

Version: 11.2.0.3

Viewed 10K+ times! This question is

You Asked

Tom,

Please answer the following two questions regarding memory allocation for SGA and background processes that I heard about 10 years ago:

1) I was told by someone that pools that make up the SGA are supposedly pre-allocated FROM THE OPERATING SYSTEM'S RAM upon database startup. Therefore, if the system has 10 gB of RAM and I set sga_target = 5000M or db_cache_size=5000M (for example) and start the database instance, THE FREE RAM ON THE DATABASE SERVER SHOULD BE REDUCED BY 5000M. Does this happen or used to happen with some operating systems? Please explain how and when all the 5000M of SGA will be allocated from the operating system. I could not find that information in neither the admin, concepts nor performance online documentation so please also point me to the document with the answer.

2) How much memory does each of the Oracle background process (SMON, PMON, ARC0, etc.) use? I had heard that we should expect each to use about about 50M of RAM. I wasn't able to find that information either in the Oracle documentation. Is all the memory per process pre-allocated when the processes start up?


Thank you for your help

and Tom said...

1) the SGA is preallocated shared memory on unixes and process memory that is reserved on windows. Since we don't touch all of the SGA (unless you make us with pre-page-sga parameters) - you might not see free memory go down straight away - until we 'touch' the memory - it could easily be paged out.

2) process memory is called PGA memory and is vieweable in the v$ tables.

ops$tkyte%ORA11GR2> select vs.program, s.sid, sn.name, round( s.value/1024/1024, 2 ) mb
  2    from v$statname sn, v$sesstat s, v$session vs
  3   where sn.statistic# = s.statistic#
  4     and vs.sid = s.sid
  5     and sn.name = 'session pga memory'
  6  /

PROGRAM                                                 SID NAME                            MB
------------------------------------------------ ---------- ----------------------- ----------
oracle@localhost.localdomain (VKTM)                       1 session pga memory             .41
oracle@localhost.localdomain (DIA0)                       2 session pga memory            1.46
oracle@localhost.localdomain (CKPT)                       3 session pga memory             .63
oracle@localhost.localdomain (MMNL)                       4 session pga memory             .66
oracle@localhost.localdomain (FBDA)                       6 session pga memory            3.34
oracle@localhost.localdomain (Q000)                       9 session pga memory            1.04
sqlplus@localhost.localdomain (TNS V1-V3)                14 session pga memory            1.34
oracle@localhost.localdomain (W001)                      15 session pga memory             .65
oracle@localhost.localdomain (GEN0)                     142 session pga memory             .41
oracle@localhost.localdomain (MMAN)                     143 session pga memory             .41
oracle@localhost.localdomain (SMON)                     144 session pga memory             .79
oracle@localhost.localdomain (QMNC)                     145 session pga memory             .41
oracle@localhost.localdomain (SMCO)                     147 session pga memory             .48
oracle@localhost.localdomain (Q001)                     148 session pga memory            3.02
oracle@localhost.localdomain (PMON)                     283 session pga memory             .43
oracle@localhost.localdomain (DIAG)                     284 session pga memory             .41
oracle@localhost.localdomain (DBW0)                     285 session pga memory            4.83
oracle@localhost.localdomain (RECO)                     286 session pga memory             .66
oracle@localhost.localdomain (PSP0)                     425 session pga memory             .41
oracle@localhost.localdomain (DBRM)                     426 session pga memory             .73
oracle@localhost.localdomain (LGWR)                     427 session pga memory            11.1
oracle@localhost.localdomain (MMON)                     428 session pga memory            1.52
oracle@localhost.localdomain (CJQ0)                     429 session pga memory            1.04
sqlplus@localhost.localdomain (TNS V1-V3)               436 session pga memory            1.53

24 rows selected.




this memory is dynamically allocated and can grow and shrink over time.


there is other memory associated with the processes - function stack memory, you can use OS tools to review that (but don't forget to take out the SGA!!! most tools will report the attached shared memory as well)

Rating

  (2 ratings)

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

Comments

John Cantu, January 17, 2013 - 12:31 pm UTC

Thank you for enlightening me on this important information.

So does the paging cause database performance problems since operating systems are allowed to page out pages from 'shared pool' and 'buffer cache pools'?

Also, regarding the background process memory usage. There is the PGA and the 'other memory associated with the proceses' that you mentioned. Roughly, how much Maximum total physical OS RAM can the 'other memory' can allocated byby all 20+ 11g background processes? Is it like <50M or 50-100M or 500+ M or 1+gB, etc.?

Thank you


Tom Kyte
January 17, 2013 - 2:17 pm UTC

paging (reading and writing memory to/from disk) affects the performance of everything on the machine more or less (in a negative fashion)

the amount of memory used by the backgrounds varies, you can sum up the pga memory - but you'd have to use an OS utility to measure the other ram used by them. It'll be megabytes typically - not gigabytes.

query on pdbs

jithu, March 15, 2022 - 3:49 pm UTC

Hi

If we execute the sql

elect vs.program, s.sid, sn.name, round( s.value/1024/1024, 2 ) mb
2 from v$statname sn, v$sesstat s, v$session vs
3 where sn.statistic# = s.statistic#
4 and vs.sid = s.sid
5 and sn.name = 'session pga memory'

in the CDB level ,will this provide us with the results of PDB level processes as well.

The actual intend of the question was to find out whether any of our application sessions in any of our pdbs inside the CDB is holding up SGA

Thanks
JIthu
Connor McDonald
March 16, 2022 - 3:36 am UTC

Yes

SQL> select con_id, count(*)
  2  from v$sesstat
  3  group by con_id;

    CON_ID   COUNT(*)
---------- ----------
         1       5922
         3       1974
         0     151998