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 ru
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
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 <[EMAIL PROTECTED]> wrote:
> Your process has parts of SGA attached to it. The only way to actually find
> out
> is to examine the process address space
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 and see how big is the RSS (resident set size).
On 11/17/2003 02:09:26 AM, "Daiminger, Helmut" wrote:
> Hi,
>
>
Helmut,
Seems a bit high to me as well. Concerning the PGA issue, what about running
something like :
col name format A25
select n.name,
round(min(s.value) / 1024) "MIN K",
round(avg(s.value) / 1024) "AVG K",
round(max(s.value) / 1024) "MAX K"
from v$statname n,
v$ses
Hi Stephane,
thanks for your reply.
We are measuring the values by getting the OS process ID of a specific
Oracle connection and then trach that process ID using glance (on HP-UX).
Since the SGA is ab 1.5 GB, it is definitely not attached to the memory
consumed by each process. I know that this
Helmut,
I don't know how you are measuring your numbers, but beware that what the operating
system reports is often somewhat misleading. Typically, shared memory is often
'attributed' to each and every process linked to it. When you think about it it makes
sense, but at the same time it does
