| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Size of oracle background processes
A copy of this was sent to Anil Kamath <akk_16_at_yahoo.com>
(if that email address didn't require changing)
On Wed, 29 Sep 1999 17:35:18 GMT, you wrote:
>
>
>Its not the size of the SGA itself..I know the SGA is shared by
>all the Oracle background processes. The problem is that
>when I do a "top" on the solaris box each of the background SQL
>processes have a resident size of approximately the same size of the
>SGA..This will create too much swapping on the
>box Why should the size of these background processes be so
>huge. What is the connection between the resident size of the background
>processes and the SGA, Shouldn't they be independent of each other.
>
No -- the top command reports the SGA as well. They are not independent of eachother.
for example, top shows:
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND 13412 tkyte 1 -15 0 126M 117M sleep 0:00 0.00% oracle
but -- pmap shows:
# /usr/proc/bin/pmap -x 13412
13412: oracleoracle8 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
Address Kbytes Resident Shared Private Permissions Mapped File 00010000 16000 10912 10016 896 read/exec oracle 00FBE000 152 152 88 64 read/write/exec oracle 00FE4000 424 312 - 312 read/write/exec [ heap ] 80000000 109552 109552 - 109552 read/write/exec/shared [shmid=0x66] EF590000 16 16 16 - read/exec libmp.so.2 EF5A2000 8 8 8 - read/write/exec libmp.so.2 EF5B0000 88 80 80 - read/exec libm.so.1 EF5D4000 8 8 8 - read/write/exec libm.so.1 EF5E0000 24 16 16 - read/exec libaio.so.1 EF5F4000 8 8 8 - read/write/exec libaio.so.1 EF5F6000 8 - - - read/write/exec [ anon ] EF600000 592 560 560 - read/exec libc.so.1 EF6A2000 32 32 8 24 read/write/exec libc.so.1 EF6AA000 8 8 - 8 read/write/exec [ anon ] EF6C0000 16 16 16 - read/exec libc_psr.so.1 EF6E0000 32 32 32 - read/exec libsocket.so.1 EF6F6000 8 8 8 - read/write/exec libsocket.so.1 EF6F8000 8 - - - read/write/exec [ anon ] EF700000 448 336 336 - read/exec libnsl.so.1 EF77E000 40 40 8 32 read/write/exec libnsl.so.1 EF788000 24 24 - 24 read/write/exec [ anon ] EF7A0000 8 8 8 - read/exec libdl.so.1 EF7B0000 8 8 - 8 read/write/exec [ anon ] EF7C0000 120 120 120 - read/exec ld.so.1 EF7EC000 8 8 8 - read/write/exec ld.so.1 EFFF6000 40 40 - 40 read/write/exec [ stack ]-------- ------ ------ ------ ------ total Kb 127680 122304 11344 110960
So, taking away the SGA size of 109552, we can sort of find the 'real' size...
If the disks aren't spinning -- it ain't swapping.
>-anil
>
>In article <7ss63n$q07$1_at_birch.prod.itd.earthlink.net>,
> "Winnie Liu" <winnie_liu_at_infonet.com> wrote:
>> I'm sorry if I got your message wrong. But what is the problem for the
>700MB
>> SGA database to have a combined shared memory usage size of
>approximately
>> 700MB (which will be shared by all the background oracle processes).
>If your
>> box is running too slow. Maybe there is too much swapping going on.
>Increase
>> the swap space or simply decrease the SGA size.
>>
>> Winnie Liu
>> DBA
>> Infonet Services Corporation
>> mailto:winnie_liu_at_infonet.com
>>
>> Anil Kamath wrote in message <7srili$vks$1_at_nnrp1.deja.com>...
>> >
>> >
>> >My SGA for Oracle 8.0.5 is configured to utilize 700 MB of memory.
>> >What I see is that my background processes (dbw,reco,chpt...etc..)
>> >show a resident memory size of approximately 700MB. Whats wrong with
>> >this picture. This make my Solaris 2.6 box slow. Is this normal.
>> >If so,,then what is the solution..
>> >
>> >-anil
>> >
>> >
>> >--
>> >Anil Kamath
>> >SmartOnline Inc. (www.smartonline.com)
>> >
>> >
>> >Sent via Deja.com http://www.deja.com/
>> >Before you buy.
>>
>>
--
See http://osi.oracle.com/~tkyte/ for my columns 'Digging-in to Oracle8i'...
Current article is "Part I of V, Autonomous Transactions" updated June 21'st
Thomas Kyte tkyte_at_us.oracle.com Oracle Service Industries Reston, VA USA
Opinions are mine and do not necessarily reflect those of Oracle Corporation Received on Thu Sep 30 1999 - 07:49:08 CDT
 |
 |