Re: Shared Memory Per Process

From: andrew_webby at hotmail <spam_at_no.thanks.com>
Date: Wed, 25 Apr 2001 10:11:24 +0100
Message-ID: <988189930.26071.0.nnrp-08.c30bdde2@news.demon.co.uk>

Yep, I made that mistake at first as well.

See the following example:

$ ps -ef|grep oracle|more
<snip>
  oracle 204 1 0 00:52:12 ? 0:00 oracleHOUTEST (LOCAL=NO) <snip>

$ /usr/proc/bin/pmap 204
204: oracleHOUTEST (LOCAL=NO)

00010000  23528K read/exec         /oracle/8.1.6/bin/oracle
01718000    216K read/write/exec   /oracle/8.1.6/bin/oracle
0174E000    456K read/write/exec     [ heap ]
80000000 104152K read/write/exec/shared  [ shmid=0x7 ]

...and so on.

Notice the size of that shared segment? But all the processes connect to that segment. Unfortunately, that's what TOP is including....

"Mick Rice" <donotreply_at_interbulletin.bogus> wrote in message news:3AE59B43.5E2E1852_at_interbulletin.com...
> Oracle 734 on Solaris 2.6
>
> I am a bit confused by what appears to be the large
> amount of shared memory used by oracle connections on
> the solaris box I'm working on. It looks like ordinary
> database connections are taking upwards of 400mb each.
> The server has 4GB virtual memory yet because of the
> seeming over use of shared memory by ordinary connections
> there's very little left spare on the box. Any insights
> would be appreciated. I've attached some details of memory
> use on the box but to be honest they don't mean a lot to me.
> I don't have access to a unix sysadmin at the moment, and
> perhaps that's where the explanation lies. The user concerned
> has been assigned the default Oracle profile,
>
> Mick Rice
>
> uname -a
>
> SunOS chan1 5.6 Generic_105181-23 sun4u sparc SUNW,Ultra-4
>
> load averages: 0.64, 0.86, 1.03

 16:08:12
> 242 processes: 237 sleeping, 1 running, 4 on cpu
> CPU states: 79.3% idle, 13.0% user, 5.6% kernel, 2.2% iowait, 0.0% swap
> Memory: 4096M real, 263M free, 601M swap in use, 1447M swap free
>
> PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
> 17555 clarify 4 0 0 13M 6992K run 0:01 2.25% cbbatch
> 11946 ora734 1 38 0 404M 400M sleep 1:06 1.90% oracle
> 6537 ora734 1 58 0 401M 397M sleep 2:59 1.85% oracle
> 6932 ora734 1 0 0 2048K 1600K cpu0 1:21 1.03% top
> 643 root 1 25 10 18M 11M cpu2 822:44 0.51% PatrolAgent
> 7675 ora734 1 28 0 399M 394M sleep 3:18 0.40% oracle
> 1743 patroldu 1 3 10 4384K 1520K sleep 265:18 0.32% bgscollect
> 21584 root 1 48 0 23M 17M sleep 164:03 0.20% esd
> 16875 ora734 1 58 0 398M 394M sleep 0:03 0.15% oracle
> 18679 ora734 1 58 0 401M 397M sleep 1:21 0.14% oracle
> 11984 clarify 5 48 0 10M 3952K sleep 8:01 0.14% rulemgr
> 19524 ora734 1 58 0 404M 399M sleep 2:36 0.12% oracle
> 23760 ora734 1 48 0 403M 398M sleep 1:03 0.09% oracle
> 18172 ora734 1 38 0 398M 394M sleep 0:06 0.09% oracle
> 15062 root 193 100 -20 3736K 3088K sleep 146:37 0.09% rpc.pmfd
>
>
> sysdef |grep -i sem
> sys/semsys
> * IPC Semaphores
> 2100 entries in semaphore map (SEMMAP)
> 2100 semaphore identifiers (SEMMNI)
> 2200 semaphores in system (SEMMNS)
> 2200 undo structures in system (SEMMNU)
> 2000 max semaphores per id (SEMMSL)
> 10 max operations per semop call (SEMOPM)
> 1500 max undo entries per process (SEMUME)
> 32767 semaphore maximum value (SEMVMX)
> 16384 adjust on exit max value (SEMAEM)
>
> sysdef |grep -i shm
> sys/shmsys
> 471859200 max shared memory segment size (SHMMAX)
> 1 min shared memory segment size (SHMMIN)
> 1700 shared memory identifiers (SHMMNI)
> 1550 max attached shm segments per process (SHMSEG)
>
>
> _______________________________________________
> Submitted via WebNewsReader of http://www.interbulletin.com
>
Received on Wed Apr 25 2001 - 04:11:24 CDT