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>