Re: how much memory does a dedicated connection take up

andreyNSPAM_at_bookexchange.net (NetComrade) wrote in message news:<3e7b7f29.2175381693_at_nyc.news.speakeasy.net>...
> Has anybody ever calculated this properly on solaris 2.7 (64bit)
> ps -ef|grep LOC
> oracle 16182 1 0 14:50:35 ? 0:11 oracleBSBL (LOCAL=NO)
>
> An article here suggests:
> http://www.akadia.com/services/solaris_tips.html
> (total minus shared), but I am having a hard time to believe that my
> connections take up 30 Megs. (sort_area_size is 32K)
> Trying to move away from MTS (just tired with it), but don't know if I
> can allow thousands of dedicated connections on the machine
> (application doesn't support connection pooling)
> Or should I just look at pga in v$sessstat? (for this session)
>
> session pga memory
> 748140
> session pga memory max
> 748140
>
> Looks like it's kind of close to heap (as suggested by Tom Kyte)
> http://asktom.oracle.com/pls/ask/f?p=4950:8:166696416062103318::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:267215452482,
>
> /usr/proc/bin/pmap 16182
> 16182: oracleBSBL (LOCAL=NO)
> 00010000 26496K read/exec
> /u31/app/oracle/product/817/bin/oracle
> 019FE000 264K read/write/exec
> /u31/app/oracle/product/817/bin/oracle
> 01A40000 976K read/write/exec [ heap ]
> 80000000 742744K read/write/exec/shared [ shmid=0xb59 ]
> FEA82000 8K read/write/exec [ anon ]
> FEA94000 8K read/write/exec [ anon ]
> FEAA6000 8K read/write/exec [ anon ]
> FEAB8000 8K read/write/exec [ anon ]
> FEACA000 8K read/write/exec [ anon ]
> FEADC000 8K read/write/exec [ anon ]
> FEAEE000 8K read/write/exec [ anon ]
> FEB00000 8K read/write/exec [ anon ]
> FEB12000 8K read/write/exec [ anon ]
> FEB24000 8K read/write/exec [ anon ]
> FEB36000 8K read/write/exec [ anon ]
> FEB48000 8K read/write/exec [ anon ]
> FEB5A000 8K read/write/exec [ anon ]
> FEB6C000 8K read/write/exec [ anon ]
> FEB7E000 8K read/write/exec [ anon ]
> FEB90000 8K read/write/exec [ anon ]
> FEB9E000 8K read/write/exec [ anon ]
> FEC00000 4056K read/exec
> /u31/app/oracle/product/817/lib/libjox8.so
> FF004000 160K read/write/exec
> /u31/app/oracle/product/817/lib/libjox8.so
> FF02C000 8K read/write/exec [ anon ]
> FF090000 16K read/exec
> /usr/platform/sun4u/lib/libc_psr.so.1
> FF0A0000 8K read/write/exec [ anon ]
> FF0B0000 16K read/exec /usr/lib/libmp.so.2
> FF0C2000 8K read/write/exec /usr/lib/libmp.so.2
> FF0D0000 88K read/exec /usr/lib/libm.so.1
> FF0F4000 8K read/write/exec /usr/lib/libm.so.1
> FF100000 664K read/exec /usr/lib/libc.so.1
> FF1B4000 32K read/write/exec /usr/lib/libc.so.1
> FF1BC000 8K read/write/exec [ anon ]
> FF1D0000 8K read/exec /usr/lib/libkstat.so.1
> FF1E0000 8K read/write/exec /usr/lib/libkstat.so.1
> FF1F0000 32K read/exec /usr/lib/librt.so.1
> FF206000 8K read/write/exec /usr/lib/librt.so.1
> FF210000 32K read/exec /usr/lib/libaio.so.1
> FF226000 8K read/write/exec /usr/lib/libaio.so.1
> FF230000 8K read/exec /usr/lib/libsched.so.1
> FF240000 8K read/write/exec /usr/lib/libsched.so.1
> FF250000 8K read/write/exec/shared [ anon ]
> FF260000 24K read/exec /usr/lib/libgen.so.1
> FF274000 16K read/write/exec /usr/lib/libgen.so.1
> FF280000 528K read/exec /usr/lib/libnsl.so.1
> FF312000 32K read/write/exec /usr/lib/libnsl.so.1
> FF31A000 32K read/write/exec [ anon ]
> FF330000 32K read/exec /usr/lib/libsocket.so.1
> FF346000 16K read/write/exec /usr/lib/libsocket.so.1
> FF350000 8K read/write/exec [ anon ]
> FF360000 32K read/exec
> /u31/app/oracle/product/817/lib/libdsbtsh8.so
> FF376000 8K read/write/exec
> /u31/app/oracle/product/817/lib/libdsbtsh8.so
> FF378000 8K read/write/exec [ anon ]
> FF380000 8K read/exec
> /u31/app/oracle/product/817/lib/libskgxp8.so
> FF390000 8K read/write/exec
> /u31/app/oracle/product/817/lib/libskgxp8.so
> FF3A0000 8K read/exec /usr/lib/libdl.so.1
> FF3B0000 128K read/exec /usr/lib/ld.so.1
> FF3DE000 16K read/write/exec /usr/lib/ld.so.1
> FFBE0000 64K read/write/exec [ stack ]
> total 776776K
> .......
> We use Oracle 8.1.7.4 on Solaris 2.7 boxes
> remove NSPAM to email

The 30M from total 776776K minus the shared memory segment 742744K is not right. All memory segments of permission not showing "write" should also be substracted. So the biggest missing chunk is obviously the oracle binary itself. Even common sense says the image of this binary should be shared by all oracle processes.

But "session pga memory" in v$sesstat is still larger than even just the heap segment in pmap -x. PGA must be a very restricted concept, not equivalent to the private memory used by an OS process. In pmap output, stack is absolutely private. Shared libraries have private portion. Even the oracle executable has a little bit (presumable data and bss segments in it). All these contribute to the memory usage of an oracle process. BTW, pmap is wrong in reporting some part of memory as private when it's shared (most notibly the shared memory segment!). This bug still exists in Solaris 8. You need the correct version from www.solarisinternals.com.

Yong Huang Received on Wed Mar 26 2003 - 12:55:58 CST