Working Sets

[Peter Clarke]

Hi

When i do a "mon proc/cont" i can see page faults increasing and therefore the working set also increases,however when the process activates a new image the working set has already decreased and has to increase again is there a way that i can set it to not decrease as much or to start at a higher value??
Also the working set value that i see is for example "1295" and when it decreases it goes to say "154" these values seem low as my wsdef on the uaf record is 2000.Are they measured in different units or is it not using the uaf values???

Thanks

Peter

[Ian Miller.]

the working set list size is reset to WSDEF on image rundown. The WS size will go down as the image exits.

You are probably seeing the difference between one value in 8k alpha pages and 512byte pagelets (as used in UAF settings etc).

[Peter Clarke]

Also if the process is a batch process or a sub-process would it still use the ws value on the uaf record or would it use the pql_dwsdefault value.

Reg

Peter

[John Gillings]

Peter,

>Also if the process is a batch process
>or a sub-process would it still use the
>ws value on the uaf record or would it
>use the pql_dwsdefault value

The PQL_D* values are "defaults" they are only used when a quota value is not provided when the process is created. Any process that is created with an explicit or implicit *username* (interactive login, batch job, network job, subprocess) always has a complete list of quotas specified. Those quotas come from the UAF or the parent process for subprocesses. It's only DETACHED processes where it's possible to omit a particular quota. In practice I recommend always specifying ALL quotas for detached processes. (I've seen far too many processes fail due to dependence on non-standard PQL_D* values, it's best to run your system so that PQL_D's are never used).

PQL_M* parameters apply to ALL processes and are the minimum value any process can have. Any resultant quota which is lower than the corresponding PQL_M* parameter will be increased to the minimum.

For BATCH jobs there is a further source of WORKING SET related quotas, those specified on the queue. See SET QUEUE/WSDEFAULT/WSQUOTA/WSEXTENT. This allows you to grant higher than normal quotas for batch jobs.

WS quotas are always specified in terms of 512 byte "pagelets", but in several places they are displayed in physical pages. This can be confusing.

Remember there is a difference between the working set SIZE (just a number) and the number of pages present (real allocation). See F$GETJPI(pid,"WSSIZE") for the SIZE, F$GETJPI(pid,"PPGCNT")+F$GETJPI(pid,"GPGCNT") for the actual used and F$GETJPI(pid,"WSPEAK") for the maximum size reached. There's no cost to having a larger working set than you're actually using, and the payoff is you don't need to incur pagefaults to trigger working set expension.

On a modern system with plenty of memory, raising WSDEFAULTs is unlikely to cause any real problems, and may reduce overall page faulting. I'd guess that there are many systems "out there" where historic UAF values for WSDEFAULT are way too low relative to the actual resource available.

Where you might get into slight difficulty is if you have many processes competing for memory, the system may be forced into more "drastic" methods of memory reclaimation. But remember, what was "drastic" and "expensive" on a VAX-11/750 isn't anything near as much of a problem on an Alpha.

Some simple calculations should tell you what "reasonable" values are for your number of processes and the amount of physical memory available.

For example, your WSDEFAULT of 2000 pages is less than 1MB. How many processes do you have (hundreds?) and how much memory (GB?). I'm recommend erring on the side of generosity - you paid good money for that memory, SO USE IT! Keep those processes well fed and happy.

At the other end, default AUTOGEN has effectively disabled UAF values for WSEXTENT by setting PQL_MWSEXTENT to WSMAX. Unless you've overridden the AUTOGEN setting (and believe you have good reason!) then you can ignore WSEXTENTS and just let OpenVMS do what it thinks best.

"Back then" we had to have a relatively complex mechanism to control how "scarce" memory was distributed between processes, and system performance was quite sensitive to fine tuning working sets. Today it's much less of an issue, just crank up those knobs and watch your system fly!

[Peter Clarke]

Yes John,i have on average 6 - 7 hundred processes and i have 8GB of memory in the machine.
My uaf values on all users at the moment are:

wsdef - 2000
wsquota - 4000
wsextent - 16384

However when i do a @working_set.com i see that the values used are the pql values which are:

pql_dwsdefault - 17616
pql_mwsdefault - 17616
pql_dwsquota - 35232
pql_mwsquota - 35232
pql_dwsextent - 151552
pql_mwsextent - 151552

Any suggestions on what i should set my values to??

Thanks

Peter

[Wim Van den Wyngaert]

Peter,

pql_m* is also used for creating the startup process (t.i. boot). If you lower them the system MIGHT have problems.
The pql_m* settings depend the usage of memory by the application programs. There is no general rule but on my GS160 default is 1888 old pages, wsq 3776 and wsext 131072. Thus a lot lower than on your system.

Wim

[John Gillings]

Peter,

>My uaf values on all users at the moment are:
>wsdef - 2000
>wsquota - 4000
>wsextent - 16384
>i see that the values used are the pql values which are:
>pql_mwsdefault - 17616
>pql_mwsquota - 35232
>pql_mwsextent - 151552

Correct! The PQL_M* values override the lower values in the UAF. Do you know where these values come from? AUTOGEN?

>6 - 7 hundred processes and i have 8GB of memory in the machine

So let's say 1GB for the OS, leaving 7 for processes. So it's 1GB per hundred processes. An even distribution would be around 21000 pagelets, so your resulting WSDEFAULT of 17616 is perfectly reasonable. PQL_MWSEXTENT is on the low side for a system with that much memory. What is WSMAX set to?

Going back to your original question:

>working set value that i see is
>for example "1295" and when it
>decreases it goes to say "154"

If these numbers are from SHOW PROCESS/CONTINUOUS then the value labelled "Working set" is *residency*, not *size*. You can see the difference as

residency=F$GETJPI(pid,"PPGCNT")+F$GETJPI(pid,"GPGCNT")

size=F$GETJPI(pid,"WSSIZE")*16

The *16 is required on Alpha because WSSIZE is in PAGES while PPGCNT and GPGCNT are in PAGELETS. PPGCNT are process private pages in the working set, GPGCNT are global pages.

So, WSSIZE should never drop below WSDEFAULT, but, naturally, when you activate a new image, the residency will drop to "nothing" and then build as the image faults in pages as required. There's not a lot you can do about this (except maybe install any heavily used images /SHARED or even /RESIDENT - you still incur faults, but they're "global valid" instead of from disk).

If WSDEFAULT were too low, when an image is activated, the residency would grow to WSDEFAULT, then you'd have to incur some page faulting in and out, until the system noticed and expanded your working set. It's the paging out that you want to avoid. On the other hand, if there is plenty of free memory, chances are those pages are not being written to disk, just put onto the modified page list, and faulted back in from there.

Have a look at MONITOR PAGE to see what type of page faults you're getting. You can't avoid them all, but you can often tune them from "bad" to "good".

[Ian Miller.]

As the great Steve Hoffman often says 'Whats the real problem you are trying to solve?'

Is there a real performance impact or are you chasing numbers? If this is research to better understand the system then thats fine (and can be fun :-), but if not.

Does the application(s) do the job fast enough or not? The important thing with performance tuning is to pick the correct metric - this will be something visible to the business (like time taken to perform a specific business operation) not system metrics like pagefault rates. System metrics are great for understanding the system behaviour but the business (who pay the bills) don't care about pagefault rates.

[Wim Van den Wyngaert]

I would like to confirm John's remarks : if wsdefault is too low, a lot of pagefaults must be done before you get a bigger working set. I once had a show que command that took 30 seconds because its working set started too small and it didn't receive additional memory fast enough.

In my opinion, you should increase (if needed) the sysuaf values in such a way that they are used instead of the pql_m ones. Then lower the pql_m ones. E.g. users doing only a telnet don't need that much memory.

I think you now are wasting a lot of memory ...

Wim

[Ian Miller.]

beware lowering the PQL_M* system parameters. Sometimes this leads to Bad Things !

The advice on always specify quotas and don't reley on PQL_M*, and PQL_D* should be heeded.

[Lawrence Czlapinski]

As Ian, said is there a performance issue or are you trying to understand your system loads better? If you are having an actual memory bottleneck, it would be helpful to have more details about it.
AVAIL_MAN is good for many things including monitoring memory usage on a number of systems all at once. AVAIL_MAN can give a list of processes with memory page counts, working set size, etc. based on criteria you select.
Your original message, didn't say what Architecture you were on. From your later message of having 600-700 processes, I deduced your on an Alpha (since production Itanium OpenVMS not yet available).
1. The PQL_MWSDEF,PQL_MSWQUO and PQL_MSWEXTENT are minimum values for processes created by the Create Process system service or the DCL command RUN (process). First check whether the values are hardcoded in MODPARAMS.DAT. If not the values may being generated by AUTOGEN or being calculated by DECWindows or someother program. If the system parameters are hardcoded in MODPARAMS.DAT, they can be modified in SYS$SYSROOT:[SYSEXE]MODPARAMS.DAT with MIN_ or MAX_ values. In your case, you would want to set a MAX_. Then run AUTOGEN. If your value is too low, DECWindows will override it. Usually PQL_MSWEXTENT isn't a problem since the system will only give out memory above a processes WSQUO if there is sufficient free pages available.

2. If there is a problem, "As a rule, the total of all resident process working set quotas should be within the amount of free memory available on the system." from Guide To OpenVMS Performance Manual, 3.6 Understanding the Memory Resource
As, Ian said, it is better to specifiy values than to rely on the PQL_* values.
Using a maximum of 700 processes * 512 bytes per pagelet, gives over 22,000 pages per process. Most system will never get WS counts even as high as 5000, and TCPIP processes can get above 6000.
So PQL_MWSDEF and PQL_DWSDEF of 17616 may not be that high for a maximum workload of 700 or less processes. However, most processes don't need that high a minimum.
If you're having a performance problem related to memory, I would start as you did with @WORKING_SET.COM. Since it has so many processes I would probably do a set host/log 0, so I could save the output unless your procedure has a /OUTPUT parameter.
As previously mentioned, it is good to have some business performance measurements before making any changes. That way you have a way of seeing if progress is being made.
I would start by trying to lower MAX_PQL_MWSQUO and MAX_PQL_DWSQUO, since if your memory is tight, you can wind up with a lot of hard page faulting from process swapping since the SWAPPER may not be able to get much memory if any by trimming down to PQL_MWSQUO when it needs memory.
Lawrence