Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Heapdump Interpretation

Re: Heapdump Interpretation

From: Danisment Gazi Unal (ubTools) <dunal_at_ubTools.com>
Date: Sat, 24 Aug 2002 05:28:19 -0800
Message-ID: <F001.004BF161.20020824052819@fatcity.com>


Hi,

I stopped developing iOraDumpReader. If I can get request, I can start again and I can add other dump iterpretation such as rbs, redolog, index, data block dump interpretations.

btw,

I've developed another web based product. It's coming soon. It's surprise now.

best regards...

--
Danisment Gazi Unal

http://www.ubTools.com
Web-based Oracle Database Products



Bill Buchan wrote:


>
> 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_at_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_at_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).
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Danisment Gazi Unal (ubTools) INET: dunal_at_ubTools.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_at_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 - 08:28:19 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US