interpretting pmap -x output

[Mark Stoltzfus]

We're running DB2 on several of our 6800s, and we're trying to get a
handle on exactly how the memory is being divided up. Specifically, I'm
interested in what's shared between processes and what isn't. This is on
Solaris 8. Looking at the pmap output for one of the 3000 db2sysc processes
running on the system yields the following:

mercedes[ROOT][11:51am][~] pmap -x 7611
7611: db2sysc
Address Kbytes Resident Shared Private Permissions Mapped File
00010000 24944 7560 6664 896 read/exec db2sysc
0187A000 1144 808 176 632 read/write/exec db2sysc
01998000 984 944 - 944 read/write/exec [ heap ]
10000000 29008 29008 - 29008 read/write/exec/shared [ ism shmid=0x2d003 ]
12000000 51216 51216 - 51216 read/write/exec/shared [ ism shmid=0x23004 ]
16000000 907936 907936 - 907936 read/write/exec/shared [ ism shmid=0x5c806 ]
4E000000 18496 18496 - 18496 read/write/exec/shared [ ism shmid=0xc2d876 ]
FC000000 6424 2312 1344 968 read/exec libdb2.so.1
FC654000 2376 968 80 888 read/write/exec libdb2.so.1
FC8A6000 608 - - - read/write/exec libdb2.so.1
FD800000 512 512 - 512 read/write/exec/shared [ ism shmid=0xf000 ]
FE402000 8 8 - 8 read/write [ anon ]
FE504000 8 8 - 8 read/write [ anon ]
FE606000 8 8 - 8 read/write [ anon ]
FE708000 8 8 - 8 read/write [ anon ]
FE80A000 8 - - - read/write [ anon ]
FE90C000 8 8 - 8 read/write [ anon ]
FEA0E000 8 - - - read/write [ anon ]
FEB0C000 8 8 - 8 read/write [ anon ]
FEB10000 8 8 - 8 read/write [ anon ]
FEC0E000 8 8 - 8 read/write [ anon ]
FEF40000 200 184 176 8 read/exec libdb2licm.so
FEF80000 32 32 - 32 read/write/exec libdb2licm.so
FEF90000 24 24 16 8 read/exec nss_files.so.1
FEFA6000 8 8 - 8 read/write/exec nss_files.so.1
FEFB0000 8 8 - 8 read/write/exec [ anon ]
FEFC0000 8 8 - 8 read/exec libdpdcf.a
FEFD0000 8 8 - 8 read/write/exec libdpdcf.a
FEFE4000 8 8 8 - read/write [ anon ]
FEFF2000 8 8 - 8 read/write [ anon ]
FF000000 680 680 672 8 read/exec libc.so.1
FF0BA000 32 32 - 32 read/write/exec libc.so.1
FF0E0000 8 8 - 8 read/write/exec/shared [ anon ]
FF0F0000 16 16 8 8 read/exec libmp.so.2
FF104000 8 8 - 8 read/write/exec libmp.so.2
FF110000 120 120 112 8 read/exec libthread.so.1
FF13E000 8 8 - 8 read/write/exec libthread.so.1
FF140000 48 40 - 40 read/write/exec libthread.so.1
FF150000 8 8 - 8 read/exec libc_psr.so.1
FF160000 8 8 - 8 read/write/exec [ anon ]
FF170000 256 160 144 16 read/exec libC.so.5
FF1BE000 32 32 16 16 read/write/exec libC.so.5
FF1C6000 56 8 - 8 read/write/exec libC.so.5
FF1E0000 24 24 16 8 read/exec librt.so.1
FF1F6000 8 8 8 - read/write/exec librt.so.1
FF200000 88 64 56 8 read/exec libm.so.1
FF224000 8 8 8 - read/write/exec libm.so.1
FF230000 208 184 72 112 read/exec libresolv.so.2
FF274000 16 8 - 8 read/write/exec libresolv.so.2
FF278000 8 8 - 8 read/write/exec libresolv.so.2
FF280000 560 560 512 48 read/exec libnsl.so.1
FF31C000 32 32 16 16 read/write/exec libnsl.so.1
FF324000 32 16 - 16 read/write/exec libnsl.so.1
FF340000 32 32 24 8 read/exec libaio.so.1
FF358000 8 8 - 8 read/write/exec libaio.so.1
FF360000 8 8 - 8 read/exec libw.so.1
FF370000 40 40 32 8 read/exec libsocket.so.1
FF38A000 8 8 - 8 read/write/exec libsocket.so.1
FF390000 8 8 - 8 read/exec libdl.so.1
FF3A0000 8 8 - 8 read/write/exec [ anon ]
FF3B0000 152 152 144 8 read/exec ld.so.1
FF3E6000 8 8 - 8 read/write/exec ld.so.1
FFBE4000 48 48 - 48 read/write [ stack ]
-------- ------ ------ ------ ------
total Kb 1046616 1022472 10304 1012168
mercedes[ROOT][11:52am][~]

According to [url]www.sun.com/sun-on-net/performance/vmsizing.pdf[/url] (which may
not apply to Solaris 8, I dunno), the determination of what a process really
owns (i.e. what's not shared) and hence what should be used as a sizing
determination is the "Private" total mentioned above. If that were true in
our case, though, for 3000 db2sysc processes we'd need about 30 terabytes of
memory (which is ironically what prstat -a reports that the DB user is
consuming). What am I missing here? Can I just strip out the stuff that's
listed as shared and then sum up the private space that remains to get a
better picture? Is there a more accurate/exact way to do this?

Curious,

Mark

[Duncan Baillie]

Get a hold of the RMCmem package off sun.com or somesuch. That will give
you the tools you need and some good explanations of what's being shared
and what isn't.

Regards

Duncan Baillie

Mark Stoltzfus wrote:

>We're running DB2 on several of our 6800s, and we're trying to get a
>handle on exactly how the memory is being divided up. Specifically, I'm
>interested in what's shared between processes and what isn't. This is on
>Solaris 8. Looking at the pmap output for one of the 3000 db2sysc processes
>running on the system yields the following:
>
>mercedes[ROOT][11:51am][~] pmap -x 7611
>7611: db2sysc
> Address Kbytes Resident Shared Private Permissions Mapped File
>00010000 24944 7560 6664 896 read/exec db2sysc
>0187A000 1144 808 176 632 read/write/exec db2sysc
>01998000 984 944 - 944 read/write/exec [ heap ]
>10000000 29008 29008 - 29008 read/write/exec/shared [ ism shmid=0x2d003 ]
>12000000 51216 51216 - 51216 read/write/exec/shared [ ism shmid=0x23004 ]
>16000000 907936 907936 - 907936 read/write/exec/shared [ ism shmid=0x5c806 ]
>4E000000 18496 18496 - 18496 read/write/exec/shared [ ism shmid=0xc2d876 ]
>FC000000 6424 2312 1344 968 read/exec libdb2.so.1
>FC654000 2376 968 80 888 read/write/exec libdb2.so.1
>FC8A6000 608 - - - read/write/exec libdb2.so.1
>FD800000 512 512 - 512 read/write/exec/shared [ ism shmid=0xf000 ]
>FE402000 8 8 - 8 read/write [ anon ]
>FE504000 8 8 - 8 read/write [ anon ]
>FE606000 8 8 - 8 read/write [ anon ]
>FE708000 8 8 - 8 read/write [ anon ]
>FE80A000 8 - - - read/write [ anon ]
>FE90C000 8 8 - 8 read/write [ anon ]
>FEA0E000 8 - - - read/write [ anon ]
>FEB0C000 8 8 - 8 read/write [ anon ]
>FEB10000 8 8 - 8 read/write [ anon ]
>FEC0E000 8 8 - 8 read/write [ anon ]
>FEF40000 200 184 176 8 read/exec libdb2licm.so
>FEF80000 32 32 - 32 read/write/exec libdb2licm.so
>FEF90000 24 24 16 8 read/exec nss_files.so.1
>FEFA6000 8 8 - 8 read/write/exec nss_files.so.1
>FEFB0000 8 8 - 8 read/write/exec [ anon ]
>FEFC0000 8 8 - 8 read/exec libdpdcf.a
>FEFD0000 8 8 - 8 read/write/exec libdpdcf.a
>FEFE4000 8 8 8 - read/write [ anon ]
>FEFF2000 8 8 - 8 read/write [ anon ]
>FF000000 680 680 672 8 read/exec libc.so.1
>FF0BA000 32 32 - 32 read/write/exec libc.so.1
>FF0E0000 8 8 - 8 read/write/exec/shared [ anon ]
>FF0F0000 16 16 8 8 read/exec libmp.so.2
>FF104000 8 8 - 8 read/write/exec libmp.so.2
>FF110000 120 120 112 8 read/exec libthread.so.1
>FF13E000 8 8 - 8 read/write/exec libthread.so.1
>FF140000 48 40 - 40 read/write/exec libthread.so.1
>FF150000 8 8 - 8 read/exec libc_psr.so.1
>FF160000 8 8 - 8 read/write/exec [ anon ]
>FF170000 256 160 144 16 read/exec libC.so.5
>FF1BE000 32 32 16 16 read/write/exec libC.so.5
>FF1C6000 56 8 - 8 read/write/exec libC.so.5
>FF1E0000 24 24 16 8 read/exec librt.so.1
>FF1F6000 8 8 8 - read/write/exec librt.so.1
>FF200000 88 64 56 8 read/exec libm.so.1
>FF224000 8 8 8 - read/write/exec libm.so.1
>FF230000 208 184 72 112 read/exec libresolv.so.2
>FF274000 16 8 - 8 read/write/exec libresolv.so.2
>FF278000 8 8 - 8 read/write/exec libresolv.so.2
>FF280000 560 560 512 48 read/exec libnsl.so.1
>FF31C000 32 32 16 16 read/write/exec libnsl.so.1
>FF324000 32 16 - 16 read/write/exec libnsl.so.1
>FF340000 32 32 24 8 read/exec libaio.so.1
>FF358000 8 8 - 8 read/write/exec libaio.so.1
>FF360000 8 8 - 8 read/exec libw.so.1
>FF370000 40 40 32 8 read/exec libsocket.so.1
>FF38A000 8 8 - 8 read/write/exec libsocket.so.1
>FF390000 8 8 - 8 read/exec libdl.so.1
>FF3A0000 8 8 - 8 read/write/exec [ anon ]
>FF3B0000 152 152 144 8 read/exec ld.so.1
>FF3E6000 8 8 - 8 read/write/exec ld.so.1
>FFBE4000 48 48 - 48 read/write [ stack ]
>-------- ------ ------ ------ ------
>total Kb 1046616 1022472 10304 1012168
>mercedes[ROOT][11:52am][~]
>
> According to [url]www.sun.com/sun-on-net/performance/vmsizing.pdf[/url] (which may
>not apply to Solaris 8, I dunno), the determination of what a process really
>owns (i.e. what's not shared) and hence what should be used as a sizing
>determination is the "Private" total mentioned above. If that were true in
>our case, though, for 3000 db2sysc processes we'd need about 30 terabytes of
>memory (which is ironically what prstat -a reports that the DB user is
>consuming). What am I missing here? Can I just strip out the stuff that's
>listed as shared and then sum up the private space that remains to get a
>better picture? Is there a more accurate/exact way to do this?
>
>Curious,
>
>Mark
>
>

[Anthony Mandic]

Mark Stoltzfus wrote:

>
> We're running DB2 on several of our 6800s, and we're trying to get a
> handle on exactly how the memory is being divided up. Specifically, I'm
> interested in what's shared between processes and what isn't. This is on
> Solaris 8.

Don't you configure DB2 to use a certain amount of shared memory?

> According to [url]www.sun.com/sun-on-net/performance/vmsizing.pdf[/url] (which may
> not apply to Solaris 8, I dunno), the determination of what a process really
> owns (i.e. what's not shared) and hence what should be used as a sizing
> determination is the "Private" total mentioned above. If that were true in
> our case, though, for 3000 db2sysc processes we'd need about 30 terabytes of
> memory (which is ironically what prstat -a reports that the DB user is
> consuming). What am I missing here? Can I just strip out the stuff that's
> listed as shared and then sum up the private space that remains to get a
> better picture? Is there a more accurate/exact way to do this?

What does ipcs show for shared memory consumption? It will report
the size and the processes. Examine it.

-am © 2003

[Mark Stoltzfus]

In article <3F278CEF.88885DCA@hotmail.com>,
Anthony Mandic <os@hotmail.com> wrote:

>Mark Stoltzfus wrote:

>>
>> We're running DB2 on several of our 6800s, and we're trying to get a
>> handle on exactly how the memory is being divided up. Specifically, I'm
>> interested in what's shared between processes and what isn't. This is on
>> Solaris 8.

>
> Don't you configure DB2 to use a certain amount of shared memory?

Yes, but I'm not interested in the shared memory segments themselves, which
are easy to report on. I'm interested in how everything else is divided up.

>> According to [url]www.sun.com/sun-on-net/performance/vmsizing.pdf[/url] (which may
>> not apply to Solaris 8, I dunno), the determination of what a process really
>> owns (i.e. what's not shared) and hence what should be used as a sizing
>> determination is the "Private" total mentioned above. If that were true in
>> our case, though, for 3000 db2sysc processes we'd need about 30 terabytes of
>> memory (which is ironically what prstat -a reports that the DB user is
>> consuming). What am I missing here? Can I just strip out the stuff that's
>> listed as shared and then sum up the private space that remains to get a
>> better picture? Is there a more accurate/exact way to do this?

>
> What does ipcs show for shared memory consumption? It will report
> the size and the processes. Examine it.

Again, less interested in the shared memory, more interested in what's left
over. It turns out that pmem (the memtool util) gives me exactly what I was
looking for.

Thanks,

Mark