CHRIS@ENGVAX.SCG.HAC.COM.UUCP (03/19/87)
I really hate to open this can of worms, but I feel that I must relay what
I have been taught about the WSxxx parameters in Authorize and the system
parameter WSMAX. This is partially in response to Jerry's letter to Info-Vax
responding to someone who had installed new memory and wanted to know what to
modify in each user's SYSUAF. I agree with most of what Jerry said, though I
disagree about what WSquo should be set at. The short-winded way to say it is
that I have been shown that a WSquo *SHOULD* be set for the worst case (i.e.
leave it low).
The long-winded explanation follows:
First, my biases:
1) Autogen is generally pretty intelligent, but only if you help it by using
MODPARAMS.DAT. (See NOTE on Autogen at the end of this for more discussion on
this.)
2) VMS is very intelligent in the way that it manages memory.
3) Memory should be used to the fullest extent possible.
4) Swapping in a general use VMS environment is very, very bad.
With these biases in mind, we come up with the following steps for setting
the Working Set parameters. (NOTE: This is not a generalized tuning session,
and environments well away from the norm may not find this information useful.)
1) Run Autogen. This will set the SYSGEN parameter WSMAX for you, also, as
Jerry mentioned, make sure that BALSETCOUNT is appropriate for your system.
I would argue that you never want to have more than BALSETCOUNT processes
resident in memory because process swapping is *VERY* expensive. Let the
Swapper start swapping when you run out of memory, not when you hit
BALSETCOUNT.
2) Set WSextent for all users to be equal to WSMAX. This means that if memory
is available and the user needs it, that user will get as much memory as WSMAX
will allow. This is a maximum value only, the process will get trimmed if the
other processes need memory.
3) Set WSdef to something low (we use 200). This is the default number of
pages that the user gets *whenever* that user starts up a new program. In
other words, every time that a user starts up a new program, that number of
pages *must* be paged in. If WSdef is set high for a program, that user will
be wasting time paging all that extra memory into place. If WSdef is set a bit
low, the user would have had to fault in the extra pages anyway. The point
here is, if it's a big job, startup time is long, so the time grabbing more
memory than WSdef is negligible. If it's a small job, startup time is short,
so the time grabbing more memory than you need is wasted when you don't want
it to be.
4) Set WSquo to something low (we use 512). You really don't want to swap.
Once all processes are trimmed to WSquo, the swapper starts to swap processes
in and out of memory.
When a process has less than WSquo pages in memory and it requests more
memory, it is guaranteed to get that memory. When a process has between WSquo
and WSextent pages in memory, it will be allowed more memory if there are more
than BORROWLIM pages free. The process will then be allowed to take as many
pages as it needs up to the point where there are GROWLIM pages free. In more
precise terminology, the system will grant a process WSINC additional pages
(but only up to the point where the system has GROWLIM pages free) if your page
fault rate is PFRATH or more for an interval of time equal to AWSTIME providing
that there are BORROWLIM pages free.
(NOTE: BORROWLIM > FREEGOAL > GROWLIM > FREELIM is the order that Autogen will
set up these parameters. You can really hose yourself if you get FREEGOAL >
BORROWLIM or FREELIM > GROWLIM.)
When there are FREELIM pages free, the swapper trims processes down
towards, but no lower than, WSquo in an attempt to free up memory so that it
can reach FREEGOAL pages on the free page list. If all processes are at WSquo
when the swapper tries to free up memory, then it has to free up memory by
taking a process out of memory and putting it into the swap file.
Overall, I feel that a process is better off very tightly cramped for
memory than on disk... At least the process can run! At this point, one
should be in the process of purchasing more memory at the very least. Also, I
feel that the more gentle degradation of performance of an increasing
page-fault rate as more processes are competing for the same amount of memory
thus having a smaller space to run in is far better than the I/O and memory
intensive operation of swapping one process out of memory and onto disk just so
that another process doesn't page-fault as much. (i.e. a few extra page faults
all the time hurts less than bunches of page faults each time processes are
moved from memory onto disk and back).
What this boils down to is a memory management policy like the one that is
stated above. Leave WSdef and WSquo low, and boost WSextent to WSMAX. This
allows users to get as many pages as they need, when they need it, but if
competition for memory is tight, then people will run in smaller spaces 'till
the page-fault rate kills the system or you buy more memory.
-- Chris Yoder UUCP -- {allegra or ihnp4}!scgvaxd!engvax!chris
Hughes Aircraft Company Internet -- @ymir.bitnet:chris@engvax.scg.hac.com
ARPA -- chris%engvax.uucp@usc-oberon.usc.edu
Disclaimer: This message has been generated entirely by line noise, my fingers
don't even claim responsibility for it.
Autogen NOTE:
When VMS V.x came out, people thought that 8 meg was an enormous amount of
memory to have on a 780. Now, I'm low man on the memory totem pole with 14 meg
in a 785. (Even our uVAX as 16!) When people upgraded from VMS 3.x to 4.x,
AUTOGEN attempted to save the old system parameters in OLDSITE.* files and
after the upgrade it sort of munged this old data in, usually with less than
optimal results. At some DECUS sessions, it was very strongly suggested that
you use the INITIAL parameter when using AUTOGEN to avoid AUTOGEN using these
files. Thus the typical AUTOGEN call should be:
@SYS$UPDATE:AUTOGEN GETDATA SETPARAMS INITIAL
What this does is it forces all input to AUTOGEN to come from
MODPARAMS.DAT and your system's hardware configuration. This makes it a bit
more obvious where AUTOGEN is coming up with the numbers for the system
parameters that it sets. One bit of warning, if you've had your system since
before VMS 4.x, there may be some parameters in your OLDSITE.* files that
you've forgotten about... Just make sure that everything that you need to
modify is in MODPARAMS.DAT.
By giving AUTOGEN information in MODPARAMS about things that are unique to
your site, AUTOGEN will come up with reasonable numbers for the other
parameters. Mucking about with most system parameters directly is more likely
to land you in deep kaka than to get you a better running system.