Re: UGA inside PGA, yes or no?
- From: Stefan Koehler <contact@xxxxxxxx>
- To: "mark.powell2@xxxxxxx" <mark.powell2@xxxxxxx>, jonathan@xxxxxxxxxxxxxxxxxx, ORACLE-L <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 2 Feb 2017 23:57:23 +0100 (CET)
Hey Mark,
If the UGA in not part of the PGA then why does a dump of the PGA Heaps
produce the UGA Heap as part of its output?
I agree with Jonathan. The dump code is very old and it dumps private heaps
(top-level PGA, UGA and call heap) or recursive levels of it depending on
the used level. In addition we also talk about some deep internals
implementation here - mentioning/differing such details would confuse most
people
out there i guess. Just another example: You also say "memory for
hash-aggregation is allocated in PGA" and not "memory for hash-aggregation is
allocated in UGA and respectively in session heap -> kxs-heap-w -> QERGH
hash-agg".
What does physically stored in the PGA mean anyway in this context since the
PGA as far as I know is not a single contiguous chunk of memory to
begin with. Aren't the posted blocks just pointers and sizes of chunks of
memory allocated from available memory on request?
Now we are getting really deep, but this is based on how heap memory is handled
by the OS (or better said on top of the stack) - do not only think
about the PGA memory allocation (chunks in heaps) from Oracle's point of view.
Let's keep it very simple and look at the graphic in this article
(
http://www.linuxjournal.com/article/6390?page=0,0) and read the following
explanation:
UNIX-based systems have two basic system calls that map in additional memory:
* brk:brk() is a very simple system call. brk() simply moves that location
forward or backward, to add or remove memory to or from the process.
* mmap:mmap() is like brk() but is much more flexible. It can map memory in
anywhere, not just at the end of the process.
Now if you think about the dynamically (de-)allocated heaps, sub-heaps,
sub-sub-heaps (from Oracle's point of view) and map this to how heap memory is
handled by the OS - i think it makes sense to source out various PGA
allocations into other top-level heaps to be able to free it "on the fly" and
give it back to the OS.
Best Regards
Stefan Koehler
Independent Oracle performance consultant and researcher
Website:
http://www.soocs.de
Twitter: @OracleSK
Upcoming online seminar:
http://tinyurl.com/17-06-13-Shared-Pool-Internals
Jonathan Lewis <jonathan@xxxxxxxxxxxxxxxxxx> hat am 2. Februar 2017 um 21:53
geschrieben:
1) Tradition
2) O/S is going outside my scope, but I think if the UGA is an arbitrarily
growing subheap of the PGA then it's not safe to deallocate excess PGA
memory because bits of the UGA might be inside the PGA chunk.
Regards
Jonathan Lewis
________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on behalf
of Powell, Mark <mark.powell2@xxxxxxx>
Sent: 02 February 2017 20:08:26
To: ORACLE-L
Subject: Re: UGA inside PGA, yes or no?
Just some ramblings
If the UGA in not part of the PGA then why does a dump of the PGA Heaps
produce the UGA Heap as part of its output? What does physically stored in
the PGA mean anyway in this context since the PGA as far as I know is not a
single contiguous chunk of memory to begin with. Aren't the posted
blocks just pointers and sizes of chunks of memory allocated from available
memory on request? So isn't the UGA location (PGA vs SGA) just a logical
location when not stored in the SGA? With dedicated server Oracle just takes
the memory for the UGA out of the same pool as the PGA hence logically
it is in the PGA.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
