|
Home > Archive > Unix Programming > April 2006 > Shared libs not shared !?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Shared libs not shared !?
|
|
| yhebib@gmail.com 2006-04-27, 7:56 am |
| Hello,
I have about 20 applications and 200 static libs on Solaris 8.
All these applications are statically linked with the needed libraries.
I am migrating all the libraries to shared libs.
I managed to get one of the main applications linked with the shared
libs.
Now, I wanted to measure the effective gain in mem usage with this new
application that use shared libs instead of static libs.
However, I do not see any mem. usage benefit with shared libs using
unix commands I know of !?
I'm interested in solaris 8 as well as AIX 5.1, 5.3 and
Linux Red Hat Enterprise Linux AS release 3 (Taroon Update 2)
2.4.21-15.ELsmp
I'll have to do the same libs move on these platforms.
Here is what I have experimented and my comments and understanding of
that (preceded by ==> ) based on a sample that illustrates what I'm
confused with:
% showrev
Hostname: ...
Hostid: ...
Release: 5.8
Kernel architecture: sun4u
Application architecture: sparc
Hardware provider: Sun_Microsystems
Domain: ...
Kernel version: SunOS 5.8 Generic 117350-24 Mar 2005
==> Solairs 8
% prtconf | grep Mem
Memory size: 8192 Megabytes
==> 8 Gb RAM
% psrinfo
0 on-line since 04/06/06 10:34:04
1 on-line since 04/06/06 10:34:04
2 on-line since 04/06/06 10:34:04
3 on-line since 04/06/06 10:34:04
==> 4 CPU machine
% BinaryWithSharedLibs &
[10] 28199
==> BinaryWithSharedLibs started in backgroung. pid is 28199
% pldd 28199
28199: BinaryWithSharedLibs
....
..../libDFGbind.so
....
==> BinaryWithSharedLibs uses about 160 shared libs. One of these libs
is libDFGbind.so (one of my shared libs). On these 160 shared libs, 96
are those that have been changed from static libs to shared libs.
%ls -alrt .../BinaryWithSharedLibs .../libDFGbind.so
.... 6875144 Apr 14 12:49 .../BinaryWithSharedLibs*
.... 7484864 Apr 12 15:41 .../libDFGbind.so*
==> BinaryWithSharedLibs size is 6.8Mb, libDFGbind size is 7.4 Mo
% size -fn .../libDFGbind.so
103096(.hash) + 206128(.dynsym) + 759831(.dynstr) + 76980(.rela.got) +
96(.rela.ex_shared) + 36(.rela.cpp_finidata) + 83520(.rela.data) +
65820(.rela.plt) + 2943764(.text) + 524(.init) + 144(.fini) +
378324(.exception_ranges) + 126048(.rodata) + 25664(.got) + 65872(.plt)
+ 168(.dynamic) + 56(.ex_shared) + 12(.cpp_finidata) + 231368(.data) +
4149(.data1) + 1987(.bss) + 408976(.symtab) + 976273(.strtab) +
10332(.stab.index) + 759215(.comment) + 216(.shstrtab) +
256975(.stab.indexstr) = 7485574
==> libDFGbind .text segment (code segment) is about 3Mb.
==> I'm then expecting to save at least 3Mb mem. with each new instance
of BinaryWithSharedLibs. And this does not take into account whatever
is shared by the other 95 shared libs.
% /usr/ucb/ps -auxwww | grep BinaryWithSharedLibs
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
abcdefgh 28199 0.0 1.2 163816 94464 pts/14 S 11:31:27 0:10
..../BinaryWithSharedLibs
==> One instance of BinaryWithSharedLibs uses 163816 Kb Mem (163 Mb)
% pmap -x 28199 | head -2 ; pmap -x 28199 | tail -1
28199: .../BinaryWithSharedLibs
Address Kbytes Resident Shared Private Permissions Mapped File
total Kb 163840 106888 87016 19872
==> 87016 Kb of the .../BinaryWithSharedLibs binary are shared.
% pmap -x 28199 | head -2; pmap -x 28199 | grep libDFGbind.so
28199:
/files/kplus_dev_obj/kplus_ref/kplus0405/Libs/DealManager/sun4sol/opt/
Address Kbytes Resident Shared Private Permissions Mapped File
FA400000 4640 2288 2288 - read/exec
libDFGbind.so
FA896000 328 328 - 328 read/write/exec
libDFGbind.so
==> 2288 Kb (2.3 Mb) counts for the segments shared by libDFGbind.
==> Already lost about 700 Kb (3 Mb - 2.3 Mb). 3 Mb is the .text
segment size as seen above
Now the thing is, if I start say 20 instances of BinaryWithSharedLibs
they will all report with ps about the same mem usage !? I also have
the same figures with pmap.
pmap reporting the figures on a process basis, this sounds ok.
Therefore, ps behaves the same way and does not make any distinctions
with whatever is shared by processes ?
I tried to track mem usage the other way round. Not by looking at mem
used by processes but looking at mem still available on the machine
with vmstat.
% vmstat 5
procs memory page disk faults
cpu
r b w swap free re mf pi po fr de sr s0 s1 s2 s3 in sy cs
us sy id
....
1 0 0 14107488 6266672 2225 10118 57 0 0 0 0 0 0 0 0 4412 21157 7276
81 17 1
==> Mem still available is 6266672 Kb (6.2 Gb)
I got the same differences with vmstat. Say I have 6 Gb available
before starting any BinaryWithSharedLibs.
I start the first one, I now have 5.9 Gb available. One instance of
BinaryWithSharedLibs took 100 Mb of memory.
If I start 20 BinaryWithSharedLibs, the amount of mem. available drops
to about 3.9 Gb. Which means that each new instance took another 100
Mb.
I write again my introducing question:
How can I measure the effective gain in mem usage for these new
applications that use shared libs instead of static libs ?
Cheers,
YH
| |
| Chuck Dillon 2006-04-27, 7:56 am |
| yhebib@gmail.com wrote:
> Hello,
>
> I have about 20 applications and 200 static libs on Solaris 8.
> All these applications are statically linked with the needed libraries.
>
> I am migrating all the libraries to shared libs.
> I managed to get one of the main applications linked with the shared
> libs.
>
> Now, I wanted to measure the effective gain in mem usage with this new
> application that use shared libs instead of static libs.
> However, I do not see any mem. usage benefit with shared libs using
> unix commands I know of !?
If you run 20 *different* programs that all link to the *same* set of
*static* libraries the system will have mapped 20 copies of each of
those libraries.
If you run 20 *different* programs that all link to the *same* set of
*shared* libraries the system only has to map *one* copy of each shared
library.
If you only have one program you won't save any memory since the system
only loads one copy in either case. In the shared case, you'll
actually probably lose a small amount of memory.
The primary point here is the system is smart enough to only load one
copy of an executable (i.e. program binarys and shared libraries)
regardless of how many processes need them at the time.
HTH,
-- ced
> I'm interested in solaris 8 as well as AIX 5.1, 5.3 and
> Linux Red Hat Enterprise Linux AS release 3 (Taroon Update 2)
> 2.4.21-15.ELsmp
> I'll have to do the same libs move on these platforms.
>
> Here is what I have experimented and my comments and understanding of
> that (preceded by ==> ) based on a sample that illustrates what I'm
> confused with:
>
> % showrev
> Hostname: ...
> Hostid: ...
> Release: 5.8
> Kernel architecture: sun4u
> Application architecture: sparc
> hardware provider: Sun_Microsystems
> Domain: ...
> Kernel version: SunOS 5.8 Generic 117350-24 Mar 2005
> ==> Solairs 8
>
>
> % prtconf | grep Mem
> Memory size: 8192 Megabytes
> ==> 8 Gb RAM
>
>
> % psrinfo
> 0 on-line since 04/06/06 10:34:04
> 1 on-line since 04/06/06 10:34:04
> 2 on-line since 04/06/06 10:34:04
> 3 on-line since 04/06/06 10:34:04
> ==> 4 CPU machine
>
>
> % BinaryWithSharedLibs &
> [10] 28199
> ==> BinaryWithSharedLibs started in backgroung. pid is 28199
>
>
> % pldd 28199
> 28199: BinaryWithSharedLibs
> ...
> .../libDFGbind.so
> ...
> ==> BinaryWithSharedLibs uses about 160 shared libs. One of these libs
> is libDFGbind.so (one of my shared libs). On these 160 shared libs, 96
> are those that have been changed from static libs to shared libs.
>
>
> %ls -alrt .../BinaryWithSharedLibs .../libDFGbind.so
> ... 6875144 Apr 14 12:49 .../BinaryWithSharedLibs*
> ... 7484864 Apr 12 15:41 .../libDFGbind.so*
> ==> BinaryWithSharedLibs size is 6.8Mb, libDFGbind size is 7.4 Mo
>
>
> % size -fn .../libDFGbind.so
> 103096(.hash) + 206128(.dynsym) + 759831(.dynstr) + 76980(.rela.got) +
> 96(.rela.ex_shared) + 36(.rela.cpp_finidata) + 83520(.rela.data) +
> 65820(.rela.plt) + 2943764(.text) + 524(.init) + 144(.fini) +
> 378324(.exception_ranges) + 126048(.rodata) + 25664(.got) + 65872(.plt)
>
> + 168(.dynamic) + 56(.ex_shared) + 12(.cpp_finidata) + 231368(.data) +
> 4149(.data1) + 1987(.bss) + 408976(.symtab) + 976273(.strtab) +
> 10332(.stab.index) + 759215(.comment) + 216(.shstrtab) +
> 256975(.stab.indexstr) = 7485574
> ==> libDFGbind .text segment (code segment) is about 3Mb.
> ==> I'm then expecting to save at least 3Mb mem. with each new instance
>
> of BinaryWithSharedLibs. And this does not take into account whatever
> is shared by the other 95 shared libs.
>
>
> % /usr/ucb/ps -auxwww | grep BinaryWithSharedLibs
> USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
> abcdefgh 28199 0.0 1.2 163816 94464 pts/14 S 11:31:27 0:10
> .../BinaryWithSharedLibs
> ==> One instance of BinaryWithSharedLibs uses 163816 Kb Mem (163 Mb)
>
>
> % pmap -x 28199 | head -2 ; pmap -x 28199 | tail -1
> 28199: .../BinaryWithSharedLibs
> Address Kbytes Resident Shared Private Permissions Mapped File
>
> total Kb 163840 106888 87016 19872
> ==> 87016 Kb of the .../BinaryWithSharedLibs binary are shared.
>
>
> % pmap -x 28199 | head -2; pmap -x 28199 | grep libDFGbind.so
> 28199:
> /files/kplus_dev_obj/kplus_ref/kplus0405/Libs/DealManager/sun4sol/opt/
> Address Kbytes Resident Shared Private Permissions Mapped File
>
> FA400000 4640 2288 2288 - read/exec
> libDFGbind.so
> FA896000 328 328 - 328 read/write/exec
> libDFGbind.so
> ==> 2288 Kb (2.3 Mb) counts for the segments shared by libDFGbind.
> ==> Already lost about 700 Kb (3 Mb - 2.3 Mb). 3 Mb is the .text
> segment size as seen above
>
>
> Now the thing is, if I start say 20 instances of BinaryWithSharedLibs
> they will all report with ps about the same mem usage !? I also have
> the same figures with pmap.
> pmap reporting the figures on a process basis, this sounds ok.
> Therefore, ps behaves the same way and does not make any distinctions
> with whatever is shared by processes ?
>
>
> I tried to track mem usage the other way round. Not by looking at mem
> used by processes but looking at mem still available on the machine
> with vmstat.
>
>
> % vmstat 5
> procs memory page disk faults
> cpu
> r b w swap free re mf pi po fr de sr s0 s1 s2 s3 in sy cs
> us sy id
> ...
> 1 0 0 14107488 6266672 2225 10118 57 0 0 0 0 0 0 0 0 4412 21157 7276
> 81 17 1
> ==> Mem still available is 6266672 Kb (6.2 Gb)
>
>
> I got the same differences with vmstat. Say I have 6 Gb available
> before starting any BinaryWithSharedLibs.
> I start the first one, I now have 5.9 Gb available. One instance of
> BinaryWithSharedLibs took 100 Mb of memory.
> If I start 20 BinaryWithSharedLibs, the amount of mem. available drops
> to about 3.9 Gb. Which means that each new instance took another 100
> Mb.
>
>
> I write again my introducing question:
> How can I measure the effective gain in mem usage for these new
> applications that use shared libs instead of static libs ?
>
> Cheers,
>
> YH
>
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
| |
| Fred Kleinschmidt 2006-04-27, 7:56 am |
|
"Chuck Dillon" <spam@nimblegen.com> wrote in message
news:e2831d$iip$1@grandcanyon.binc.net...
> yhebib@gmail.com wrote:
>
> If you run 20 *different* programs that all link to the *same* set of
> *static* libraries the system will have mapped 20 copies of each of those
> libraries.
>
> If you run 20 *different* programs that all link to the *same* set of
> *shared* libraries the system only has to map *one* copy of each shared
> library.
>
> If you only have one program you won't save any memory since the system
> only loads one copy in either case. In the shared case, you'll actually
> probably lose a small amount of memory.
>
> The primary point here is the system is smart enough to only load one copy
> of an executable (i.e. program binarys and shared libraries) regardless of
> how many processes need them at the time.
>
> HTH,
> -- ced
<snip>
> --
> Chuck Dillon
> Senior Software Engineer
> NimbleGen Systems Inc.
Another thing you save is disk space. If you have 20 different programs that
are statically linked, they all include the used library modules in the
executables.
If they are statically linked, none of them include anything from any of
the libraries (other than linkage hooks), and so are much smaller.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project
| |
| yhebib@gmail.com 2006-04-27, 7:56 am |
| Sure, disk space is saved. Nowadays though we're talking about Gigas or
Teras as opposed to Megas not so long ago.
Stockage prices per Mb dropped very significantly these last 20 years.
RAM, however, is still an issue.
Chuck, I got your view. However, how do you explain what I have
experimented:
vmstat tells me you have, let's say, 1 Gb available before starting any
occurence of my BinaryWithSharedLibs.
I start the 1st one. vmstat tells me you have 900 Mb available now (1
Gb - 100 Mb)
I start the 2nd one. vmstat tells me you have 800Mb available now (900
Mb - 100Mb).
and so on...
I would expect to consume more memory the 1st time than the others.
Exactly because and this is wht you stated as well, the program and the
shared libs will be loaded once only.
More accurately I woul expect :
1st instance is started :
- code segments loaded for the program and all shared libs
- data segments loaded for the 1st instance program and all shared libs
2nd instance is started :
- data segments loaded for the 2nd instance program and all shared libs
and so on...
I'm then expecting a significant difference in mem consumption between
the 1st occurence and the others.
This difference would be what I want to measure: the effective gain in
mem usage with shared libs.
Nobody else can use these shared libs, they've been built recenlty and
in my own dev. environment.
YH
| |
| Rick Jones 2006-04-27, 7:56 am |
| yhebib@gmail.com wrote:
> Chuck, I got your view. However, how do you explain what I have
> experimented:
> vmstat tells me you have, let's say, 1 Gb available before starting
> any occurence of my BinaryWithSharedLibs. I start the 1st
> one. vmstat tells me you have 900 Mb available now (1 Gb - 100 Mb) I
> start the 2nd one. vmstat tells me you have 800Mb available now (900
> Mb - 100Mb). and so on...
> I would expect to consume more memory the 1st time than the others.
> Exactly because and this is wht you stated as well, the program and
> the shared libs will be loaded once only.
Are you certain this is the first loading of the program and all the
libraries since the system was booted?
What "else" does your program allocate? Does it do malloc's or mmap's
or the like?
How big does ps or the like say each of your processes happens to be?
Does it claim that each is larger than the 100MB difference in free
memory reported by vmstat?
What does the size command say for your executable and each of the
shared libraries it uses?
rick jones
--
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway... 
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
| |
| yhebib@gmail.com 2006-04-27, 7:56 am |
| Rick,
> Are you certain this is the first loading of the program and all the
> libraries since the system was booted?
I'm *not* certain this is the first loading of the program and all the
libraries since the system was booted.
However, I'm certain nobody else uses this program or shared libs.
> What "else" does your program allocate? Does it do malloc's or mmap's
> or the like?
The program certainly does some allocation through new or malloc but
nothing reallly significant.
> How big does ps or the like say each of your processes happens to be?
> Does it claim that each is larger than the 100MB difference in free memory reported by vmstat?
% /usr/ucb/ps -auxwww | head -1; /usr/ucb/ps -auxwww | grep
BinaryWithSharedLibs
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
abcdefgh 8156 0.1 1.2 163784 93864 pts/14 S 20:54:48 0:10
BinaryWithSharedLibs
abcdefgh 8100 0.0 1.2 163832 93912 pts/14 S 20:48:48 0:10
BinaryWithSharedLibs
abcdefgh 8118 0.0 1.2 163792 93864 pts/14 S 20:50:54 0:10
BinaryWithSharedLibs
abcdefgh 8143 0.0 1.2 163784 93864 pts/14 S 20:53:14 0:09
BinaryWithSharedLibs
% vmstat 5
I give here the differences reported by vmstat.
1st diff: difference between vmstats before starting any
BinaryWithSharedLibs and after starting the 1st one.
2st diff: difference between vmstats after starting the 1st
BinaryWithSharedLibs and after starting the 2nd one
Dito for 3rd and 4th diff
5th diff: difference between vmstats before starting any
BinaryWithSharedLibs and after killing them all
memory
swap - free
1st diff : 35856 Kb - 48848 Kb
2nd diff : 36008 Kb - 19800 Kb
3rd diff : 36616 Kb - 20384 Kb
4th diff : 36328 Kb - 20096 Kb
5th diff : 368 Kb - 136 Kb
Ok, now I see a difference between the first started process and the
others for the free memory (29 Mb).
However, the available swap decreases equally (always 36 Mb)
Furthermore, 29 Mb seems not much, given pmap report (on 2 different
BinaryWithSharedLibs processes) above that says 88.5 Mb are shared.
% pmap -x 8100 | head -2 | tail -1 ; pmap -x 8408 | tail -1
Address Kbytes Resident Shared Private Permissions Mapped File
total Kb 163784 108360 88536 19824
% pmap -x 8118 | head -2 | tail -1 ; pmap -x 8408 | tail -1
Address Kbytes Resident Shared Private Permissions Mapped File
total Kb 163776 108352 88536 19816
> What does the size command say for your executable and each of the
> shared libraries it uses?
%ls -alrt BinaryWithSharedLibs
-rwxrwxr-x 1 abcdefgh zyx 6875144 Apr 20 17:15
BinaryWithSharedLibs*
(6.8Mb)
% pldd 8118 | grep MyDevDir | xargs ls -alrt | cut -c24-33 | nawk '{
sum += $1 } END { print sum }'
117133280 This is the size of all the shared libs. they all reside in
MyDevDir
(117Mb)
% pldd 8118 | grep MyDevDir | xargs -i mysize.ksh {} | grep '.text' |
cut -d'(' -f1 | nawk '{ sum += $1 } END { print sum }'
(mysize.ksh is a specific size -fn that displays each section on a
separate line)
38665032 This is the .text sections size for all the shared libs.
(38 Mb)
This means that I'm expecting at least 38Mb to be shared (all the code
segments).
Certainly more than that since it is my understanding that other
sections than the .text sections are shared between processes.
Cheers,
YH
| |
| Rick Jones 2006-04-27, 7:56 am |
| yhebib@gmail.com wrote:
> I'm *not* certain this is the first loading of the program and all the
> libraries since the system was booted.
> However, I'm certain nobody else uses this program or shared libs.
So, if the system happened to keep those text pages in memory, "just
in case" the memory drop you see after the "first" loading may not
include the loading of those text pages.
> The program certainly does some allocation through new or malloc but
> nothing reallly significant.
> % /usr/ucb/ps -auxwww | head -1; /usr/ucb/ps -auxwww | grep
> BinaryWithSharedLibs
> USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
> abcdefgh 8156 0.1 1.2 163784 93864 pts/14 S 20:54:48 0:10
> BinaryWithSharedLibs
> abcdefgh 8100 0.0 1.2 163832 93912 pts/14 S 20:48:48 0:10
> BinaryWithSharedLibs
> abcdefgh 8118 0.0 1.2 163792 93864 pts/14 S 20:50:54 0:10
> BinaryWithSharedLibs
> abcdefgh 8143 0.0 1.2 163784 93864 pts/14 S 20:53:14 0:09
> BinaryWithSharedLibs
> % vmstat 5
> I give here the differences reported by vmstat.
> 1st diff: difference between vmstats before starting any
> BinaryWithSharedLibs and after starting the 1st one.
> 2st diff: difference between vmstats after starting the 1st
> BinaryWithSharedLibs and after starting the 2nd one
> Dito for 3rd and 4th diff
> 5th diff: difference between vmstats before starting any
> BinaryWithSharedLibs and after killing them all
> memory
> swap - free
> 1st diff : 35856 Kb - 48848 Kb
> 2nd diff : 36008 Kb - 19800 Kb
> 3rd diff : 36616 Kb - 20384 Kb
> 4th diff : 36328 Kb - 20096 Kb
> 5th diff : 368 Kb - 136 Kb
> Ok, now I see a difference between the first started process and the
> others for the free memory (29 Mb).
> However, the available swap decreases equally (always 36 Mb)
> Furthermore, 29 Mb seems not much, given pmap report (on 2 different
> BinaryWithSharedLibs processes) above that says 88.5 Mb are shared.
> % pmap -x 8100 | head -2 | tail -1 ; pmap -x 8408 | tail -1
> Address Kbytes Resident Shared Private Permissions Mapped File
> total Kb 163784 108360 88536 19824
> % pmap -x 8118 | head -2 | tail -1 ; pmap -x 8408 | tail -1
> Address Kbytes Resident Shared Private Permissions Mapped File
> total Kb 163776 108352 88536 19816
> %ls -alrt BinaryWithSharedLibs
> -rwxrwxr-x 1 abcdefgh zyx 6875144 Apr 20 17:15
> BinaryWithSharedLibs*
> (6.8Mb)
> % pldd 8118 | grep MyDevDir | xargs ls -alrt | cut -c24-33 | nawk '{
> sum += $1 } END { print sum }'
> 117133280 This is the size of all the shared libs. they all reside in
> MyDevDir
> (117Mb)
Actually I meant size(1) not ls. Eg:
raj@tardy:~/netperf2_work$ size src/netperf
text data bss dec hex filename
89079 5284 41064 135427 21103 src/netperf
Anyway...
> Certainly more than that since it is my understanding that other
> sections than the .text sections are shared between processes.
Which other sections to you think can/are shared?
rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
| |
| Gordon Burditt 2006-04-27, 7:56 am |
| >I have about 20 applications and 200 static libs on Solaris 8.
>All these applications are statically linked with the needed libraries.
>
>I am migrating all the libraries to shared libs.
>I managed to get one of the main applications linked with the shared
>libs.
>
>Now, I wanted to measure the effective gain in mem usage with this new
>application that use shared libs instead of static libs.
How do you measure this?
>However, I do not see any mem. usage benefit with shared libs using
>unix commands I know of !?
How did you measure this?
Read carefully what the output of, say, 'ps' means on your system.
If, for example, one instance of exim uses 1 meg of program, 1 meg
of stack and allocated data, and 3 megs of shared libraries, 'ps'
on systems I've used will say it's using 5 meg (virtual). If you
have 200 instances of exim running receiving email, 'ps' will say
the same thing about EACH ONE OF THEM. If you add them all up, you
get 1000 meg, which might exceed available RAM+SWAP. However, what
you're really using is 2*200+3 = 403 meg of virtual memory.
What tool are you using that will show 403 meg, not 1000 meg, in
this situation?
Tools that show RAM use, rather than RAM+SWAP, are pretty much
useless here since the system keeps stuff in RAM in case it's
needed (therefore it's still 'in use') rather than have to
go fetch it again.
>Now the thing is, if I start say 20 instances of BinaryWithSharedLibs
>they will all report with ps about the same mem usage !? I also have
Yes, and I believe they should. How much memory a particular process
uses is *NOT* dependent on how many other processes also share the
same memory.
>the same figures with pmap.
>pmap reporting the figures on a process basis, this sounds ok.
>Therefore, ps behaves the same way and does not make any distinctions
>with whatever is shared by processes ?
If you look at the memory use by one process over time you could
see some pretty strange stuff simply because other processes using
the same shared libs run and exit.
Gordon L. Burditt
| |
| yhebib@gmail.com 2006-04-27, 7:56 am |
| > So, if the system happened to keep those text pages in memory, "just
> in case" the memory drop you see after the "first" loading may not
> include the loading of those text pages.
Agree with that Rick. I'll give it a try after a reboot.
This way we'll have "sanitized" figures.
> Actually I meant size(1) not ls. Eg:
Ooooops. I'll give the figures with size and sum up for all shared
libs.
> Which other sections to you think can/are shared?
I'll give details on this as well based on my understanding.
Off this Friday. I'll post back on Monday...
Cheers,
YH
| |
| yhebib@gmail.com 2006-04-27, 7:56 am |
| Thanx for the feedback all,
I'll get back to this post tomorrow.
I managed to get unique access to one of our dev servers and reboot it
anytime.
This way, I can get clean figures after fresh reboot.
YH
|
|
|
|
|