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>