From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: RE: Pagefile on DECram ramdisk - any comments?
Date: 31 Dec 92 12:38:55 GMT
Distribution: world
Organization: The Internet


	We are currently running a VAX 4000-300 with VMS 5.4-3.  We have 128Mb
	of memory.  We currently only have one pagefile (50,000 blocks) and
	yes, it's on the system disk (RF31).  Our other two disk drives
	(RF72's) are currently being hit so hard that a secondary pagefile on
	those disks is not possible.  I have proposed buying an RF35, but that
	will not happen until the Fall of 1993.

	We currently have a lot of memory that is not being used (170,000+
	blocks).  Working set sizes have been tuned so folks are getting the
	memory they deserve.  I have been exploring the possibility of
	installing a secondary pagefile on to a DECram ramdisk of say,
	60,000-70,000 blocks.

	Has anyone ever done this before and if so, are there any issues that
	I should be aware of?  If I make the pagefile on the ramdisk
	sufficiently large so that it has the most Reservable pages available,
	I should be able to ensure that the secondary pagefile is used more
	often than not.  We're running DECram v1.0, and I'm getting ready to
	install v1.1 this week.

Think about what you are proposing:  Pages go to the pagefile when there is
no room for them (for whatever reason) in memory.  You propose to have them
go to - well, memory, when there is no room in memory.

While this will work, it makes very little sense.  If, as you are currently
configured, effectively all of your physical memory were in use most of the
time, the effect of installing a ramdisk would be to make your run SHORT of
memory, thus increasing paging.  And to what end?  The pages newly forced out
of memory would actually stay in memory - but they'd be shuffled around from
memory marked as "memory" to memory marked as "ramdisk", costing you CPU time.

Since your current configuration leaves a significant - in fact, huge! -
amount of memory free, you can look for other ways to make use of it.  On a
system-wide basis, you might consider decreasing FREELIM/FREEGOAL so as to
encourage pages to stay on the look-aside lists, getting pretty much the same
effect as "paging" them to a ramdisk for a LOT less overhead.  You might
consider installing /RESIDENT your most commonly used images - both the VMS
images and any 3rd-party or locally created, commonly-used images.

However, I suspect the real clue to what's going on here is in your claim that
"Working set sizes have been tuned so folks are getting the memory they
deserve".  When I hear a system manager talk about what users "deserve", it
usually implies a rather, ahem, limited view of user/system management inter-
action.  It sounds as if you are letting some arbitrary, probably decade-old
notion of the "right" amount of memory get in the way of sound system manage-
ment.

If your system HAS the memory, it's foolish not to let processes use it!  I'd
STRONGLY suggest you first re-examine your policies and standards in this
direction to see if they make any sense with the equipment and load you have
TODAY - not whether they made sense when you had 50 people on an 11/780.
Then set limits that will make effective use of your resources.  As a quick
calculation:  Let M be your estimate - it doesn't have to be exact - of the
maximum number of simultaneous active users your system has to deal with.  If
you have some users who sit at a prompt for long periods of time, don't count
them against M - or count them as a fraction of a user.  (Be generous with M;
it's better to estimate somewhat too high than somewhat too low.)

Now let P be the number of pages on your system, not counting those reserved
to VMS; again, this doesn't have to be exact.  Then P/(1.5*M) should be a
reasonable value for the WSQUOTA of a typical user.  WSEXTENT should be
considerably larger - as a first cut, I'd make it 4 times WSQUOTA.  (If you
have distinctly different classes of users, you can of course vary these
numbers a bit - though typically I'd no more than halve or triple WSQUOTA.
You can be much more generous with WSEXTENT; there's essentially no reason NOT
to be generous with it.)

Finally, make sure WSMAX is large enough - at least as large as the biggest
WSEXTENT, ignoring any WSEXTENT's that you might set to "infinite" (i.e., let
this user take all the memory he needs, when memory is available).  Also, if
you've modified FREELIM/FREEGOAL, make sure BORROWLIM is set rationally so
that the WSEXTENT values can contribute something.  AUTOGEN will do this for
you.

							-- Jerry