Tanel,
I've noticed that the growth of memory is done in steps. And those
steps become progressivelly large, until it can no longer allocate
memory.
Even on 64 bit systems, a single workarea is limited to 4 gb. And
because of this step allocations, allocation actually stops at arround
3.5 gb (instead of just under 4gb).
Have you found any way to control the step, or at least the maximum
step during step allocation ?
I wonder when they will start to support the Linux hugetlb pool for pga mem=
ory.
I've noticed that it will never de-allocate the memory, if you are
under your pga_aggregate_target. But once you start using it in
another process, it will de-allocate it.
On 5/13/05, Tanel P=F5der <tanel.poder.003_at_mail.ee> wrote:
> Hi,
>=20
> > Yes, starting from 9i, if you use automatic pga, pga memory is
> > released back to OS as needed, without exiting the process.
>=20
> Actually, it's the UGA and CGA heaps which can be released back to OS
> starting from 9i (maybe there's some trick for pure PGA memory as well, b=
ut
> I doubt it, because you cannot release some random chunks of a heap, you
> have to release the whole heap if you want to get some memory back).
>=20
> Starting from 9i, there is a parameter called _use_realfree_heap, if it i=
s
> true then Oracle allocates UGA and CGA heaps directly from OS (as top-lev=
el
> heaps). If the parameter is false, Oracle will allocate PGA as top-level
> heap and then will allocate UGAs and CGAs inside PGA. This means that PGA
> will grow as more memory is needed but will never shrink as Oracle doesn'=
t
> do physical heap shrinking, you can free the memory by getting rid of the
> whole heap.
>=20
> Also, realfree memory management uses mmap() and munmap() calls on /dev/z=
ero
> (nice trick) to allocate/deallocate memory, the old fashioned way was to =
use
> brk(). To reduce number of overhead/system calls for continuous allocatio=
n
> and deallocation of memory Oracle preallocates more memory in chunks
> controlled by _realfree_heap_pagesize_hint parameter, that way we don't h=
ave
> to do a separate system call for getting few more bytes for growing our
> heap. Oracle doesn't release the memory back to OS immediately either - i=
t
> rather wastes a bit of memory (which is likely gonna be reused anyway)
> instead of trying to do housekeeping all the time. This "wasted" memory h=
as
> always been pretty much bogus issue anyway, as this is virtual memory and
> can be easily paged out while not in use (well, unless you use intimate
> shared memory for your PGAs under Solaris using _use_ism_for_pga paramete=
r
> ;) Also, as long as you haven't touched the newly allocated virtual memor=
y
> page, no physical memory is allocated for it anyway.
>=20
> The _use_realfree_heap parameter's value defaults to true in 10g and
> defaults to true on 9.2 too IF pga_aggregate_target is > 0.
>=20
> There are couple of statistics in v$pgastat which give us indication abou=
t
> freeable PGA:
> - PGA memory freed back to OS
> - total freeable PGA memory.
>=20
> The names speak for themselves...
>=20
> I haven't tested on other platforms, but at least on Linux 2.4 Oracle
> 10.1.0.3 is using some clever trick - whenever more memory is needed, we
> actually allocate a bulk range of process virtual memory address space
> without actually allocating any virtual memory pages for it.
> It's done by calling mmap() with MAP_NORESERVE flag, this means that no s=
wap
> space will be reserved for this process, thus we might get unexpected
> results when we'd start writing into the page, but we'll know the range o=
f
> this new virtual memory now. When we actually want to use this memory, we=
'll
> start mapping virtual memory pages into this freshly allocated address sp=
ace
> in smaller quantities (in sizes of _realfree_heap_pagesize_hint value)-
> using mmap() with MAP_FIXED flag which allows us to manually specify to
> which address in process address space should the virtual memory page to =
be
> mapped.
>=20
> I guess that the reason behind that is that
> allocating/extending/initializing address space in OS kernel process
> structure is heavier operation than mapping memory to it - so it's
> reasonable to do those address space operations less frequently and use
> lightweight mapping operations (mmap() with MAP_FIXED) to make this memor=
y
> actually usable for our process (or maybe the os process structure will j=
ust
> be smaller if you do less bigger allocations instead of more smaller
> ones...)
>=20
> The "bulk" address space allocation sizes can be controlled using
> _pga_large_extent_size and _uga_cga_large_extent_size parameters, for PGA
> and UGA/CGA respectively. I guess increasing those might be helpful in
> extreme environments which are frequently allocating/deallocating big PL/=
SQL
> arrays or doing frequent hash joins/bitmap merging - where allocating mem=
ory
> would become more significant overhead than the CPU usage itself (I'm onl=
y
> guessing this, as I haven't seen such a system yet).
>=20
> ...
>=20
> And now when we finally access this memory, it's up to OS VM manager and
> hardware MMU to find physical pages of memory for our data and estabilish
> low level address translation between virtual and physical memory page...
>=20
> Huh, now that I see the length of this post... thanks to the ones who did
> read through it ;)
> Tanel.
>=20
> --
> http://www.freelists.org/webpage/oracle-l
>=20
--=20
Christo Kutrovsky
Database/System Administrator
The Pythian Group
--
http://www.freelists.org/webpage/oracle-l
Received on Fri May 13 2005 - 16:24:06 CDT
