[comp.os.vms] memory/performance tradeoff in INSTALLing files shared

DNEIMAN@carleton.EDU (01/28/88)

We have several VAXen with limited memory (8MB).  It seems to be generally
accepted that INSTALLing software SHARED/OPEN will reduce the overhead
of using that software, thereby improving system performance.  However,
by doing this, it would seem that the amount of memory available to users is
reduced, thereby forcing additional paging/swapping (and degrading system
performance).

My question:

Is there a point at which it becomes self-defeating to install software
shared/open?  If so, how can I determine where the break-even point is?

Dave Neiman
System Manager
Carleton College
Northfield, MN 55057-4040
(507) 663-4277
csnet: dneiman@carleton.edu

-------

dp@JASPER.Palladian.COM (Jeffrey Del Papa) (02/06/88)

    Date: Wed, 27 Jan 88 16:02 CST
    From: DNEIMAN%carleton.edu@RELAY.CS.NET

    We have several VAXen with limited memory (8MB).  It seems to be generally
    accepted that INSTALLing software SHARED/OPEN will reduce the overhead
    of using that software, thereby improving system performance.  However,
    by doing this, it would seem that the amount of memory available to users is
    reduced, thereby forcing additional paging/swapping (and degrading system
    performance).

    My question:

    Is there a point at which it becomes self-defeating to install software
    shared/open?  If so, how can I determine where the break-even point is?

    Dave Neiman
    System Manager
    Carleton College
    Northfield, MN 55057-4040
    (507) 663-4277
    csnet: dneiman@carleton.edu

    -------


installing files share/open/header-resident takes up trivial amounts of space in
paged and non paged pool. This is consumed by information similar to that in the
ACP. It doesn't read the program in. Shared images do consume system address
space, but that is cheap (1% of the size of the shared image size) this makes
the system page table (which must be in pre-allocated contigious real memory)
larger. this was an issue when vaxen had ~1mb, with 8 I wouldn't worry much.
Shared images save you space as soon as the second person runs it (they really
do get the same pages). the /open sqitch saves you all the overhead of looking
in the directory. the entries themselves are tiny, I don't know how efficient
the search thru the list of pre-opened files is, but almost anything is cheaper
than a disk hit (basicly the difference between open by name and open by file
id).  header resident means it reads the index file entry into paged pool,
saving even more disk cycles, on what is often one of the busiest disks of the
whole system. I encourage its use for stable peices of code. (it is traumatic
but possible to install new sections) to see how well you are doing with shared
memory, the install program will give you a list of section size/in-use with
in-use being the size time the number of current users. Since shared pages get
counted against several working sets, a simple minded program that adds up the
users working set sizes, (like one of our old display hacks) would report total
of working sets several times that of physical memory.

<dp>