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 process used by oracle

Re: Memory process used by oracle

From: Sybrand Bakker <postbus_at_sybrandb.demon.nl>
Date: Wed, 26 Jun 2002 10:56:08 +0200
Message-ID: <uhj0siotdk1d0@corp.supernews.com>

"Efraim Sánchez-Gil" <willybee_at_terra.es> wrote in message news:ce04d3b1.0206260023.622e045d_at_posting.google.com...
> Hi!
>
> I have a problem with Oracle 8.1.5 (Solaris)... he used a lot of
> memory that has not been used.
>
> Is possible tunning this??
>
> Thx
>
> This is the capture:
>
> $ ps -ef |grep ora_
> oracle86 16288 1 4 11:11:34 ? 27:27 ora_s000_boxv2
> oracle86 16290 1 0 11:11:34 ? 0:52 ora_s001_boxv2
> oracle86 16298 1 0 11:11:34 ? 0:00 ora_s005_boxv2
> oracle86 16302 1 0 11:11:34 ? 0:00 ora_s007_boxv2
> oracle86 16300 1 0 11:11:34 ? 0:00 ora_s006_boxv2
> oracle86 16278 1 0 11:11:33 ? 0:06 ora_dbw0_boxv2
> oracle86 16280 1 0 11:11:33 ? 0:08 ora_lgwr_boxv2
> oracle86 16314 1 0 11:11:34 ? 0:01 ora_arc0_boxv2
> oracle86 16306 1 0 11:11:34 ? 0:00 ora_s009_boxv2
> oracle86 16286 1 0 11:11:34 ? 0:00 ora_reco_boxv2
> oracle86 16276 1 0 11:11:33 ? 0:00 ora_pmon_boxv2
> oracle86 16304 1 0 11:11:34 ? 0:00 ora_s008_boxv2
> oracle86 16292 1 0 11:11:34 ? 0:01 ora_s002_boxv2
> oracle86 16282 1 0 11:11:34 ? 0:07 ora_ckpt_boxv2
> oracle86 16310 1 1 11:11:34 ? 18:08 ora_d001_boxv2
> oracle86 16308 1 2 11:11:34 ? 17:52 ora_d000_boxv2
> oracle86 16296 1 0 11:11:34 ? 0:00 ora_s004_boxv2
> oracle86 16312 1 1 11:11:34 ? 17:09 ora_d002_boxv2
> oracle86 16294 1 0 11:11:34 ? 0:00 ora_s003_boxv2
> oracle86 16284 1 0 11:11:34 ? 0:01 ora_smon_boxv2
> $ /usr/proc/bin/pmap -x 16288
> 16288: ora_s000_boxv2
> Address Kbytes Resident Shared Private Permissions Mapped File
> 00010000 23264 15408 11200 4208 read/exec oracle
> 016D6000 208 208 144 64 read/write/exec oracle
> 0170A000 1144 1136 - 1136 read/write/exec [ heap ]
> 80000000 115264 115264 - 115264 read/write/exec/shared
> [shmid=0x44d]
> EEFB0000 16 16 16 - read/exec libmp.so.2
> EEFC2000 8 8 - 8 read/write/exec libmp.so.2
> EEFD0000 88 80 80 - read/exec libm.so.1
> EEFF4000 8 8 - 8 read/write/exec libm.so.1
> EF000000 4872 3056 1240 1816 read/exec libjox8.so
> EF4D0000 176 176 - 176 read/write/exec libjox8.so
> EF4FC000 16 - - - read/write/exec [ anon ]
> EF510000 8 8 - 8 read/write/exec [ anon ]
> EF520000 8 8 8 - read/exec
> libkstat.so.1
> EF530000 8 8 - 8 read/write/exec
> libkstat.so.1
> EF540000 24 24 24 - read/exec
> libposix4.so.1
> EF554000 8 8 - 8 read/write/exec
> libposix4.so.1
> EF560000 24 24 24 - read/exec libaio.so.1
> EF574000 16 16 - 16 read/write/exec libaio.so.1
> EF580000 600 600 600 - read/exec libc.so.1
> EF624000 32 32 - 32 read/write/exec libc.so.1
> EF62C000 8 8 - 8 read/write/exec [ anon ]
> EF640000 16 16 16 - read/exec
> libc_psr.so.1
> EF650000 8 8 8 - read/exec
> libsched.so.1
> EF660000 8 8 - 8 read/write/exec
> libsched.so.1
> EF670000 8 8 8 - read/write/exec/shared [
> anon ]
> EF680000 456 456 400 56 read/exec libnsl.so.1
> EF700000 40 40 - 40 read/write/exec libnsl.so.1
> EF70A000 16 8 - 8 read/write/exec [ anon ]
> EF720000 32 32 32 - read/exec
> libsocket.so.1
> EF736000 8 8 - 8 read/write/exec
> libsocket.so.1
> EF738000 8 - - - read/write/exec [ anon ]
> EF740000 8 8 - 8 read/write/exec [ anon ]
> EF750000 32 16 8 8 read/exec
> libdsbtsh8.so
> EF766000 8 8 - 8 read/write/exec
> libdsbtsh8.so
> EF768000 8 - - - read/write/exec [ anon ]
> EF770000 8 8 8 - read/exec libwtc8.so
> EF780000 8 8 - 8 read/write/exec libwtc8.so
> EF790000 8 8 8 - read/exec
> libskgxp8.so
> EF7A0000 8 8 - 8 read/write/exec
> libskgxp8.so
> EF7B0000 8 8 8 - read/exec libdl.so.1
> EF7C0000 128 128 128 - read/exec ld.so.1
> EF7EE000 16 16 - 16 read/write/exec ld.so.1
> EFFEE000 72 72 - 72 read/write/exec [ stack ]
> -------- ------ ------ ------ ------
> total Kb 146712 136968 13960 123008
> $ /usr/local/bin/top
>
> load averages: 0.25, 0.25, 0.25
> 07:31:14
> 69 processes: 68 sleeping, 1 on cpu
> CPU states: 77.2% idle, 11.7% user, 10.9% kernel, 0.2% iowait, 0.0%
> swap
> Memory: 1024M real, 36M free, 321M swap in use, 2540M swap free
>
> PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
> 19663 root 16 58 0 155M 140M sleep 6:02 0.10% java
> 16288 oracle86 1 48 0 147M 129M sleep 27:36 4.17% oracle
> 16278 oracle86 1 58 0 146M 123M sleep 0:06 0.00% oracle
> 16312 oracle86 1 58 0 146M 122M sleep 17:11 1.03% oracle
> 16310 oracle86 1 43 0 146M 122M sleep 18:12 5.77% oracle
> 16308 oracle86 1 58 0 146M 122M sleep 17:53 1.39% oracle
> 16276 oracle86 1 59 0 146M 123M sleep 0:00 0.00% oracle
> 16314 oracle86 1 59 0 146M 122M sleep 0:00 0.00% oracle
> 16282 oracle86 1 59 0 146M 122M sleep 0:07 0.01% oracle
> 16280 oracle86 1 59 0 146M 122M sleep 0:07 0.00% oracle
> 16290 oracle86 1 58 0 146M 126M sleep 0:52 0.06% oracle
> 16284 oracle86 1 58 0 146M 125M sleep 0:01 0.00% oracle
> 16286 oracle86 1 59 0 146M 125M sleep 0:00 0.00% oracle
> 8574 daemon 1 48 0 146M 124M sleep 0:00 0.09% oracle
> 16292 oracle86 1 58 0 146M 125M sleep 0:00 0.00% oracle
> 16294 oracle86 1 59 0 146M 123M sleep 0:00 0.00% oracle
> 16296 oracle86 1 59 0 146M 123M sleep 0:00 0.00% oracle
> 16302 oracle86 1 59 0 146M 123M sleep 0:00 0.00% oracle
> 16304 oracle86 1 59 0 146M 123M sleep 0:00 0.00% oracle
> 16306 oracle86 1 59 0 146M 123M sleep 0:00 0.00% oracle
> 16300 oracle86 1 59 0 146M 123M sleep 0:00 0.00% oracle
> 16298 oracle86 1 59 0 146M 122M sleep 0:00 0.00% oracle

Of course it is possible tuning this (what has happened in this group? Does it come with it's own dictionary?)
However, I think you are going from the wrong end. You should rather first tune the application, then tune the database, then start to worry about memory.
This looks like a typical configuration where someone has decided to make loads of memory available to Oracle ('Just make sure the cache is big enough, and that will work') without taking into account the tradeoffs. 1 G physical looks a bit meagre to me.
I would also definitely run the prtmem command. Solaris by default is setting up a *huge* filecache, which can and should be switched off (by using mount -forcedirectio for ufs file systems, and by using the mincache option for vxfs file system). You should also take into account most of the memory is shared. The ps command doesn't tell much.

Hth

--
Sybrand Bakker
Senior Oracle DBA

to reply remove '-verwijderdit' from my e-mail address
Received on Wed Jun 26 2002 - 03:56:08 CDT

Original text of this message

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