From: dsiebert@icaen.uiowa.edu (Doug Siebert)
Subject: Re: Shared libraries have me very confused!
Date: Thu, 27 Aug 1992 01:21:49 GMT
Organization: ISCA

In article <7371266@hpfcso.FC.HP.COM> mjs@hpfcso.FC.HP.COM (Marc Sabatella) writes:
>
>"monitor" probably reports shared library text pages as "belonging" to each
>process, so analyzing processes individually won't tell you much.  If the
>global RAM usage statistics (which probably can be trusted, but I don't know -
>after all, monitor is unsupported) show more total memory being used with
>shared libraries, then I guess we can take that at face value.  However, the
>increase in swap usage, as I explained earlier, should be expected, and does
>*not* mean "physical memory has been exhausted", unless "monitor" really is
>showing you the use of swap, and not just the reservation/allocation.  All

Monitor shows only the actual use of swap.  Actually, I wish it were the other
way around, so I could know how much swap I "reserving" at given loads, so one
day the swap doesn't just run out with possibly nasty results.  I have 150M
reserved now, hopefully that will be enough for a 48M machine that will likely
be upgraded to 96M by the end of the year.

>        Running "monitor" on #2 presumably shows 190K of memory used for text
>by the process - 100K belongs to the application, 90K to the library code.
>However, there was originally probably more like 200K of code in those
>libraries, and when you use the shared versions, "monitor" probably reports
>that 200K as belonging to each process, even though it is really shared.  So
>"monitor" probably reports around 300K of memory used for text per process.
>
>The curses library is pretty small, and can probably be discounted.  In fact,
>I don't think it is even available in shared form.  So it is really only libc
>we are talking about here.  libc actually contained >600K of text, so monitor
>will probably show any given process as requiring 510K more memory with shared
>libc than with archive libc.  But you aren't *really* using that much memory.

Well, monitor DOES count the text in the address space usage per process, but
NOT in the RSS figures.  I've cut the monitor per process statistics output
for my program, first running with archive libraries, then running with shared
libraries.  The address space figures (assuming only data and stack as being
important, of course) don't add up to the RSS in either case.

  Current resident set size:      33  (archive)
  ADDRESS SPACE USAGE IN BYTES
    Text:        192512
    Data:         86016
    Stack:        53248
 
  Current resident set size:      43  (shared)
  ADDRESS SPACE USAGE IN BYTES
    Text:         90112
    Data:         53248
    Stack:        57344

I don't have enough data yet to be able to say conclusively whether or not
recompiling my program to run its 80 invocations with archive libraries has
decreased the total memory usage or not.  I've got to wait for a time when I
hit 80 users but don't have 2 or 3 people running xterms and multiple emacs
sessions off the machine at the same time :-)

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                             | "I don't have to take this abuse |
| Internet:  dsiebert@icaen.uiowa.edu      |  from you - I've got hundreds of |
| NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
|     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/
Hi, I'm a .signature worm.  I've already copied myself into your .signature.
From: shoe@hpcuhe.cup.hp.com (Jim Schumacher)
Date: Thu, 3 Sep 1992 00:55:34 GMT
Subject: Re: odump - we don't got it
Organization: Hewlett Packard, Cupertino