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

Home -> Community -> Usenet -> c.d.o.server -> Re: Memory utilization on Sun E3500.

Re: Memory utilization on Sun E3500.

From: Antoine BRUNEL <antoinebrunel/yahoo.fr>
Date: Mon, 12 May 2003 10:57:12 +0200
Message-ID: <3ebf61e9$0$27354$79c14f64@nan-newsreader-03.noos.net>


Hi from Paris

Solaris is a beautiful, but strange system, by the way memory is managed.

What you see in SIZE columns is addition of shared memory (SGA) and private memory used by sessions. In your case, you must have defined an SGA of about 260 Mo, and processes add the SORT_AREA_SIZE, which in general is less of 1 Mo.

As I said, it is hard to know real memory use on Solaris, in the fact that all physical memory is quickly reserved in addition of some swap space. A good indicator your are really swapping is if you observe "page in / out" in vmstat reports.

"pengwin" <nospam_at_localhost.com> a écrit dans le message de news:3ebf3874$0$52255$c30e37c6_at_lon-reader.news.telstra.net...
> Hi all, we have a "development" Oracle Database on our Sun E3500. It is
chewing
> up my RAM big time and impacting on other processes, notably the "Live"
> accounting System.
>
> Our DBA, who is also the IT Manager claims that the following blocks of
Memory
> are not legit, and/or a single block of 260Mb. I laugh at him when he says
this,
> but he seems to be serious/convinced that Oracle is not chewing up the
RAM. I
> just want to get a second opinion, am I right in saying Oracle is to blame
for
> us constantly paging?
>
> This is a top sorted by "size" Comments please? If we shutdown Oracle, how
do we
> force Oracle to release the RAM (Other than a restart).
>
> load averages: 1.67, 1.58, 1.69 15:46:24
> 459 processes: 456 sleeping, 3 on cpu
> CPU states: 51.9% idle, 38.8% user, 7.3% kernel, 2.0% iowait, 0.0% swap
> Memory: 1792M real, 27M free, 705M swap in use, 3703M swap free
>
> PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
> 12386 oracle 1 26 0 262M 218M sleep 0:00 0.00% oracle
> 12643 oracle 1 18 0 261M 218M sleep 0:00 0.00% oracle
> 7372 oracle 12 53 2 261M 218M sleep 0:02 0.00% oracle
> 7370 oracle 14 53 2 258M 218M sleep 0:00 0.00% oracle
> 7374 oracle 11 52 2 256M 218M sleep 0:33 0.00% oracle
> 7376 oracle 1 42 2 256M 220M sleep 0:07 0.00% oracle
> 7368 oracle 1 53 2 256M 218M sleep 0:00 0.00% oracle
> 23702 oracle 1 28 0 255M 221M sleep 0:00 0.00% oracle
> 5900 oracle 1 38 0 255M 222M sleep 0:00 0.00% oracle
> 24475 oracle 1 24 0 255M 221M sleep 0:00 0.00% oracle
> 29339 oracle 1 27 0 255M 221M sleep 0:00 0.00% oracle
> 4183 oracle 1 28 0 255M 221M sleep 0:00 0.00% oracle
> 27225 oracle 1 28 0 255M 221M sleep 0:00 0.00% oracle
> 3967 oracle 1 28 0 255M 221M sleep 0:00 0.00% oracle
> 28334 oracle 1 28 0 255M 221M sleep 0:00 0.00% oracle
> 3547 oracle 1 28 0 255M 221M sleep 0:00 0.00% oracle
> 29459 oracle 1 38 0 255M 221M sleep 0:00 0.00% oracle
> 27282 oracle 1 38 0 255M 221M sleep 0:00 0.00% oracle
> 24470 oracle 1 52 0 255M 221M sleep 0:00 0.00% oracle
> 17766 oracle 1 38 0 255M 221M sleep 0:00 0.00% oracle
> 18663 oracle 1 38 0 255M 220M sleep 0:00 0.00% oracle
> 17939 oracle 1 59 0 255M 220M sleep 0:00 0.00% oracle
> 18665 oracle 1 28 0 255M 220M sleep 0:00 0.00% oracle
> 18691 oracle 1 34 0 255M 220M sleep 0:00 0.00% oracle
> 16219 oracle 1 28 0 255M 220M sleep 0:00 0.00% oracle
> 17491 oracle 1 35 0 255M 220M sleep 0:00 0.00% oracle
> 14463 oracle 1 24 0 255M 218M sleep 0:00 0.00% oracle
> 14457 oracle 1 38 0 255M 218M sleep 0:00 0.00% oracle
> 7378 oracle 1 52 2 255M 219M sleep 0:00 0.00% oracle
> 8502 root 4 59 0 13M 9344K sleep 1:07 0.00% _mprosrv
> 7402 root 4 59 0 12M 9416K sleep 0:07 0.00% _mprosrv
> 9616 oracle 1 48 0 11M 2704K sleep 3:56 0.00% tnslsnr
>
>
Received on Mon May 12 2003 - 03:57:12 CDT

Original text of this message

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