Well, the last number is, obviously, the size of the area. Only the maps of
shared memory, text and data are of some interest. Text is, in case of an
oracle process, $ORACLE_HOME/bin/oracle and you don't have any influence
over it. The "data" section are the auxiliary structures. If you are running
dedicated servers, it's where sort area, hash area, cursor statuses and alike
are stored. Shmem is, of course, SGA. From the listing you gave us, I'd
conclude that you're OK because SGA is by far the largest and everything else
seems very small.
On 2003.11.17 21:34, zhu chao wrote:
> Hi,
> I have also been researching on how to monitor oracle process memory
> utilization on different platform . And on hp, it seems more difficult.
> I once see a note on metalink talking about using kernel debugger on HP
> to detect it, here is a sample output, but I do not know the detailed
> meaning
> of different part. Hope some HP expert can answer it here.
> Oracle version is 9.2.0.1 and SGA is 840396160 bytes.
> $ ps -ef|grep 12436
> oracle 12436 1 0 Nov 8 ? 0:47 ora_pmon_mimidb
> oracle 21385 21369 0 10:31:33 pts/ta 0:00 grep 12436
> $top result:
> TTY PID UID PRI NI SIZE RES STATE TIME %WCPU %CPU
> COMMAND
> ? 2454 101 154 20 3676K 1036K sleep 0:10 0.02 0.02
> tnslsnr
> ? 12436 101 152 20 69696K 20332K run 0:47 0.02 0.02
> ora_pmon_mimidb
> ? 12438 101 156 20 69952K 21400K sleep 0:58 0.02 0.02
> ora_dbw0_mimidb
>
> # q4pxdb /stand/vmunix
>
> Processing Header Section...
> Processing GNTT Section...
> Processing LNTT Section...
> Procedures: 0
> Processing SLT...
> Sorting Quick Lookup Tables...
> Re-writing ELF file...
> Done.
> #
> # ied q4 /stand/vmunix /dev/mem
> @(#) q4 $Revision: 1.79a $ $Date: 97/09/08 12:00:22 $ 0
> q4: (warning) no modules in the crashdump or no INDEX file
> q4: (warning) q4 will try to read /dev/kmem for kernel access
> Reading kernel symbols ...
> Reading kernel data types ...
> /dev/mem: can't validate: expected size or checksum not available.
> Dump data may not be correct.
> Initialized PA-RISC 2.0 address translator ...
> Initializing stack tracer ...
> Get the latest Q4 news by typing "news".
> q4> load struct proc from proc max nproc
> loaded 276 struct proc's as an array (stopped by max count)
> q4> keep p_pid ==12436
> kept 1 of 276 struct proc's, discarded 275
> q4>
> q4> load struct vas from p_vas
> loaded 1 struct vas as an array (stopped by max count)
> q4> load struct pregion from va_ll.lle_prev next p_ll.lle_prev max 100
> loaded 54 struct pregion's as a linked list (stopped by loop)
> q4> print -x p_type p_space p_vaddr p_count | more
> PT_SHMEM 0x427bc00 0xc000000004000000 0x33178 --sga size=833088K
> PT_MMAP 0x427bc00 0xc000000000400000 0x549
> PT_MMAP 0x427bc00 0xc000000000240000 0x76
> PT_MMAP 0x427bc00 0xc000000000140000 0xfb
> PT_MMAP 0x427bc00 0xc000000000120000 0x15
> PT_MMAP 0x427bc00 0xc0000000000f0000 0x26
> PT_MMAP 0x427bc00 0xc0000000000e8000 0x7
> PT_MMAP 0x427bc00 0xc0000000000d0000 0x16
> PT_MMAP 0x427bc00 0xc0000000000c4000 0x7
> PT_MMAP 0x427bc00 0xc000000000040000 0x83
> PT_MMAP 0x427bc00 0xc000000000038000 0x2
> PT_MMAP 0x427bc00 0xc000000000034000 0x4
> PT_MMAP 0x427bc00 0xc000000000030000 0x4
> PT_MMAP 0x427bc00 0xc00000000002c000 0x4
> PT_MMAP 0x427bc00 0xc00000000002a000 0x1
> PT_MMAP 0x427bc00 0xc000000000000000 0x28
> PT_STACK 0x44eb800 0x800003ffff7f0000 0x10
> PT_MMAP 0x44eb800 0x800003fffc000000 0x2
> PT_MMAP 0x44eb800 0x800003fffbffe000 0x2
> PT_MMAP 0x44eb800 0x800003fff8000000 0x2
> PT_MMAP 0x44eb800 0x800003fff4000000 0x1
> PT_MMAP 0x44eb800 0x800003fff0000000 0x1
> PT_MMAP 0x44eb800 0x800003ffec07c000 0x2
> PT_MMAP 0x44eb800 0x800003ffec000000 0x7c
> PT_MMAP 0x44eb800 0x800003ffe8000000 0x2
> PT_MMAP 0x44eb800 0x800003ffe4045000 0x8
> PT_MMAP 0x44eb800 0x800003ffe4000000 0x45
> PT_MMAP 0x44eb800 0x800003ffe0000000 0x1
> PT_MMAP 0x44eb800 0x800003ffdc004000 0x1
> PT_MMAP 0x44eb800 0x800003ffdc000000 0x4
> PT_MMAP 0x44eb800 0x800003ffd8000000 0x1
> PT_MMAP 0x44eb800 0x800003ffd4000000 0x2
> PT_MMAP 0x44eb800 0x800003ffd0000000 0x1
> PT_MMAP 0x44eb800 0x800003ffcc000000 0x3
> PT_MMAP 0x44eb800 0x800003ffc800f000 0xe
> PT_MMAP 0x44eb800 0x800003ffc8000000 0xf
> PT_MMAP 0x44eb800 0x800003ffc4000000 0x2
> PT_MMAP 0x44eb800 0x800003ffc0000000 0x4
> PT_MMAP 0x44eb800 0x800003ffbc000000 0x2000
> PT_MMAP 0x44eb800 0x800003ffb8000000 0x2
> PT_MMAP 0x44eb800 0x800003ffb4018000 0x7
> PT_MMAP 0x44eb800 0x800003ffb4000000 0x18
> PT_MMAP 0x44eb800 0x800003ffb0000000 0x2
> PT_MMAP 0x44eb800 0x800003ffac005000 0x1
> PT_MMAP 0x44eb800 0x800003ffac000000 0x5
> PT_MMAP 0x44eb800 0x800003ffa8000000 0x2
> PT_MMAP 0x44eb800 0x800003ffa4000000 0x2
> PT_DATA 0x44eb800 0x8000000100000000 0x400
> PT_UAREA 0xd37f800 0x400003ffffff0000 0x8
> PT_UAREA 0xae9c000 0x400003ffffff0000 0x8
> PT_TEXT 0xbe50c00 0x4000000000000000 0x4000 13864*4K pages = 686811728 Bytes
> --$ size `which oracle`
> --67108864 + 2097152 + 80320 = 69286336
>
> PT_MMAP 0x5893000 0xc003f000 0x1
> PT_NULLDREF 0x5893000 0 0x1
> 0 0 0x41bafb00 0x41bafb00
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Monday, November 17, 2003 10:59 PM
>
>
> > Gogala,
> >
> > I've been searching for a /proc filesystem implementation on HPUX for
> years. I
> > don't think it's there yet.
> >
> > Yong Huang
> >
> > --- Mladen Gogala <mladen_at_wangtrading.com> wrote:
> > > Your process has parts of SGA attached to it. The only way to actually
> find
> > > out
> > > is to examine the process address space wia kernel debugger or /proc
> file
> > > system. First, try with ps -lp <PID> and see how big is the RSS
> (resident
> set
> > > size).
> > > On 11/17/2003 02:09:26 AM, "Daiminger, Helmut" wrote:
> > > > Hi,
> > > >
> > > > we are running 9.2 on HP-UX here.
> > > >
> > > > We have pg_aggregate_target configured, but I realized (in my opinion)
> very
> > > > high memory consumption of Oracle Unix processes.
> > > >
> > > > a) How come that one Oracle Connection (i.e. dedicated Unix process on
> HP)
> > > > is using up at least 22 MB of RAM? It is using 22 MB if the user is
> just
> > > > connected, not doing anything.
> > > >
> > > > Any way I can modify this?
> > > >
> > > > b) If the user is querying data and the like, the memory consumption
> goes
> > > up
> > > > to 60 MB. How come?
> > > >
> > > > Thanks!
> > > >
> > > > Regards,
> > > > Helmut
> > > >
> > > > --
> > > > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > > > --
> > > > Author: Daiminger, Helmut
> > > > INET: HELMUT.DAIMINGER_at_wwk.de
> > > >
> > > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > > > San Diego, California -- Mailing list and web hosting services
> > > > ---------------------------------------------------------------------
> > > > 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).
> > > >
> > >
> > > Mladen Gogala
> > > Oracle DBA
> >
> > __________________________________
> > Do you Yahoo!?
> > Protect your identity with Yahoo! Mail AddressGuard
> > http://antispam.yahoo.com/whatsnewfree
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Yong Huang
> > INET: yong321_at_yahoo.com
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting services
> > ---------------------------------------------------------------------
> > 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.net
> --
> Author: zhu chao
> INET: chao_ping_at_vip.163.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> 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).
>
--
Mladen Gogala
Oracle DBA
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Mladen Gogala
INET: mgogala_at_adelphia.net
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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 Mon Nov 17 2003 - 21:14:25 CST
