NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/hp/9733

Internet Message Format | 1992-08-26 | 5.6 KB

From: [e-mail] (Marc Sabatella)
Date: Wed, 26 Aug 1992 20:14:28 GMT
Subject: Re: Shared libraries have me very confused!
Message-ID: <[e-mail]>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Path: sparky!uunet!usc!sdd.hp.com!hpscdc!hplextra!hpfcso!mjs
Newsgroups: comp.sys.hp
References: <[e-mail]>
Lines: 107

In comp.sys.hp, [e-mail] (Doug Siebert) writes:

> No, I meant each runs in a separate process.  They are all run from the same
> i-node

OK, then you are getting an awful lot of sharing already.

> I used 'monitor' to get this information.  I went by what it told me both by
> analyzing processes individually and giving me their RSS size, and by the
> global statistics giving the overall amount of memory usage.  With 75 users
> I would dig into the first couple megabytes of swap space, though beforehand
> none was used.  I assume this means that at that point physical memory has
> been exhausted and inactive pages are being swapped out.  At some point pages
> that are just *less* active will be swapped out, and then I'll see performance
> decrease, correct?

"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
swap that a process *might* need to back up its data and bss (and that of its
libraries) is allocated at startup time in HP-UX, as well as SunOS.  AIX, I
believe, does not do this - it allocates swap as pages actually are referenced,
or possibly even only as they need to be swapped out.  The downside of the
Sun/HP was is that per-process swap allocation (albeit not actual usage) goes
up.  The downside of the AIX way is that a process may often find itself in a
position where it doesn't have enough swap to back up its own data, and there
is none available.  At this point, the system would either have to kill off
processes, or make some wait, possibly leading to deadlock and all those nasty
things.  Under the HP/Sun method, either a process has enough swap to start, or
it doesn't.  The only way a process can run out of swap during execution is
through a failed call to malloc(), which well-behaved applications can at
least recover gracefully.  Under the other approach, a process can die, or be
put on hold waiting for swap, possibly indefinitely, at any time.  Actually,
this can happen in HP-UX as well, if you try to grow your stack and there is
not enough swap to back it up, but this is a very rare occurrence.

>
> OK, I think I understand what I was missing about shared libraries.  Since this
> application is the major usage of this machine, and I'm not really concerned if
> it is a couple hundred K larger in size, I should compile with the archive
> libraries instead of the shared libraries, to avoid the overheard of swap, real
> memory, and speed associated with shared libraries, which are intended to save
> disk space over the many applications over the whole system.

Good assesment, but:

> >    cc -o program.shared $(OBJS) $(LIBS)
>
> 107889 + 1852 + 18964 = 128705
>
> >    cc -o program.archive $(OBJS) -Wl,-a,archive $(LIBS)
>
> 191028 + 12220 + 43712 = 246960
>
> >    cc -o program.none $(OBJS)
>
> 105692 + 1524 + 15468 = 122684

> I'm guessing you mistyped and meant #1 and #3 should be similar, since #2 has
> the extra overheard of *not* using shared libraries.

Correct, sorry about that, but...

> But #2 does take up less
> memory, according to monitor (though you say that may be flawed)

Right.  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.
Since this is all text, and shareable, it does't matter how many invocations
of the program are present; that's all the memory that will be needed for
text.  So it looks like the shared version needs 110K more.  However, if you
have only 2 other applications that use 90K of library text, then shared
libraries will be a win - the two other applications will need

    App1-text + 90K + App2-text + 90K

memory for text with archive libraries, whereas with shared libraries, only

    App1-text + App2-text

memory for text.  The 180K savings just wiped out the 110K cost you saw without
those 2 other applications.

> The only
> library other than libc I am using is the curses/termcap library, so there is
> not much tuning I can do in that respect.

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.

--------------
Marc Sabatella ([e-mail])
Disclaimers:
    2 + 2 = 3, for suitably small values of 2
    Bill (H.) and Dave (P.) may not always agree with me