Thanks for your help. I did use pmap to determine the private
memory use for the process (the instance itself is very small and the SGA
can actually be significantly smaller than the process memory).
I've not had a change to look at iOraDumpReader yet as we've got web
access problems here, but I'll have a look when we're back.
Thanks
- Bill.
At 11:23 23/08/2002 -0800, you wrote:
Hi,
A heap consists of memory areas named extent. Each extent consists
of memory areas named chunks.
Interpretation:
EXTENT 437
Chunk 925dfe4 sz=
1836 perm
"perm
" alo=1836
Chunk 925e710 sz=
1156 recreate "session heap
" latch=0
EXTENT 437 ---> extent number
925dfe4 ---->
chunk address
sz=
-----> size of chunk
perm
------> permanent memory class
"perm
" ------> chunk comment
Memory classes can be the followings:
- Recreatable (can be removed and then recreated when requested. i.e:
shared SQL statements)
- Free (free, no object in it)
- Freeable(used in session/call duration. I guess event10046 data is
located here)
- Permanent(for permament objects)
Each chunk in same extent is contiguous. For your case, First chunk
address(0x925dfe4) + its size(1836) = second chunk address (0x925e710)
You can not identfy the heap as UGA heap yet. Because, there is no heap
header in your email.
I had developed a tool named iOraDumpReader at
http://www.ubTools.com/products/ioradumpreader/ioradumpreader.html.
I'm mentioning here since it is free. But, I stopped developing it since
there was no interest in this product.
For your problem:
Shared memory segments such as SGA are included in process address space.
So, You may be encoutering this problem. Search metalink for 'pmap'
command.
best regards...
Bill Buchan wrote:
Hi all,
I have a process which is taking up way more memory than I'd
expected. The
process runs a PL/SQL that does some nested loop joins on a PL/SQL table.
The background process is using > 200Mb of private memory and this
number
goes up if we tweak the WHERE clause in the join to return more data.
I did a heapdump of the process and the trace file looks like this (lots
of
stuff trimmed):
...
EXTENT 437
Chunk 925dfe4 sz=
1836 perm
"perm
" alo=1836
Chunk 925e710 sz=
1156 recreate "session heap
" latch=0
ds 92693fc sz= 30315156
ct= 440
b7aa56c
sz= 3980
92f30a0
sz= 1072
afb6e34
sz= 16472
afb2dcc
sz= 16472
afaed64
sz= 16472
...
I presume that "session heap" is the UGA for this process'
session. Basically it goes on like this for several pages with sz
anywhere
between 16k and 1Mb. How can I interpret this? I presume the
memory is to
do with cursor information. This is a sort but the sort area size
is only
10Mb and cannot account for all the private memory in use.
I'm just trying to decide if this is a reasonable amount of memory to be
using (i.e. explain what it is using it *for*) and just put up with it,
or
if something has gone wrong. I'm on 8.1.5 on Linux 2.2 (I know, I
know...)
Thanks for any insight!
- Bill.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Bill Buchan
INET: wbuchan@uk.intasys.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Sat Aug 24 2002 - 07:38:21 CDT
