From: HENRY::IN%"Orphanage%sri-kl.ARPA%relay.cs.net@rca.com" 21-MAR-1987 21:37 To: info-vax@sri-kl.arpa Subj: Working Set Parameters 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.