Working set parameters usage

[Wim Van den Wyngaert]

I know that SORT uses wsextent to see how many memory can be used to sort in memory.

I know that SAS tries to eat up to wsextent as workspace.

I know that BACKUP tries to eat up to wsquota for transfer buffers.

Are there any other known abuses of the quota parameters (t.i. side effects when changing them) ?

Wim

[John Gillings]

Wim,

Loaded question?

Why do you refer to these as "known abuses"? The behaviour of SORT and BACKUP are clearly documented wrt WSEXTENT and WSQUOTA. I don't know about SAS, but I would expect that any utility or application to document such behaviour.

Different utilities have different requirements for resource usage and tuning. It's perfectly legitimate to use process quotas for this purpose. One could propose a design where a utility had an extra qualifier to control memory limits, but it would inevitably have interactions with the actual process quotas. This complicates the potential states and behaviour of the application, rather than simplifies it.

Remember that you can easily adjust working set quotas with the SET WORK command, should you need to adjust the memory consumption of a process when using a memory intensive utility or application.

[Wim Van den Wyngaert]

John,

wsextent : Specifies the working set maximum. This represents the maximum amount of physical memory allowed to the process. The system provides memory to a process beyond its working set quota only when it has excess free pages. The additional memory is recalled by the system if needed.

Sort and SAS simply take wsextent and fails if it is unavailable (in pagefile). So, a high wsextent may cause program failures. They consider wsextent as "must get" while it is "may get". That's an abuse. As you said, a parameter would be a better choice.

Backup is using wsquota. Thats a better choice.

Also check http://groups.google.com/groups?hl=nl&lr=&ie=UTF-8&threadm=38D73801.B4CCF535%40email.sps.mot.com&rnum=5&prev=/groups%3Fq%3Dwsextent%2520sort%26num%3D100%26hl%3Dnl%26lr%3D%26ie%3DUTF-8%26sa%3DN%26tab%3Dwg

Wim

[Jan van den Ende]

And, John,

if you use AUTOGEN (most of us, I guess, if only as a final phase in a VMS upgrade), then AUTOGEN nowadays set PQL_MWSEXTENT to WSMAX, so effectively WSEXTENT is ALWAYS equal th WSMAX, and as far as I know not even SET WORK can make it less.

So I guess, Wim, you gor a REAL point (once again)!

Jan

[Wim Van den Wyngaert]

Just another thing : you can decrease your quotas but you can not increase them.

So, per default you must give too much in such a way that sort can use it. But while NOT doing sort you need to decrease it. So, you need to decrease it in the login and increase it just before sort.

Wim

[Wim Van den Wyngaert]

Correction : sort doesn't fail but simply makes some noise (error messages).

I did some testing.

------------------------------
When sort starts, it will put the wssize to wsextent.

Then it tries to allocate the memory in the working set but will never go as
high as wsextent. If memory alloc fails, workfiles will be used.

A test case with a file of 247000 blocks and wsextent of 300000. The ws was
used for 227936 and work files were allocated. This while there was memory
free.

Another test case with a file of 185000 blocks and a wsextent of 300000. The ws
was used for 191552 and no work files were allocated.

Another test case with a pgflquota of 50000 and wsextent of 300000 gave
warnings about failed memory allocation but ended in success.

Another case were disk space was missing. When 1 work file could not be
written it continued to give the message for 6 others before ending the sort.


Way to limit usage : /format=file_size=xxx.

[John Gillings]

Wim,

Yes, SORT will attempt to use WSEXTENT in memory to make sure it completes as fast as possible. This is goodness! It's only a problem if PGFLQUOTA is significantly smaller than WSEXTENT.

OK, so why would anyone do that? It doesn't make any sense at all. As Jan has pointed out, by default, AUTOGEN sets PQL_MWSEXTENT to WSMAX, so what you put in the SYSUAF is irrelevant. Some system managers are surprised by that, and it can cause problems with SORT.

So, is this a bug in OpenVMS? Not at all! It's simply OpenVMS engineering trying to make your processes use the available resources, even if you're still running from a VAX 750 heritage SYSUAF which hasn't had quotas adjusted in a decade. (maybe AUTOGEN should set PQL_MPGFLQUOTA to WSMAX too, but that's another question).

Look around you! You're SWIMMING in resources. Disk is cheap, memory is cheap! Why artificially constrain your systems by not allowing processes to use available memory?

Go and check your pagefile. If it's less than 10GB, work out the real cost of disk space and realise that $10 spent on extra page file space is absurdly cheap insurance to pretty much eliminate all possibilities of lack of page file space affecting your system performance. What are your WSEXTENTs and WSMAXes? 100000 pages? Sounds big yes? It's peanuts! Just 50MB. The smallest PC you can buy today has 10 times that much memory. What about PGFLQUOTAs? If they're not measured in milions, go and increase them! I expect to see working set sizes in the 100's of Megabytes and virtual space limits (PGFLQUOTAs) in the 10's of Gigabytes.

SORT is doing its job, all you need to do is make sure the quotas you give it make sense. So crank up those WSMAX values. A quarter of physical memory is perfectly reasonable. Allocate multiple, multi GB page files, and set PGFLQUOTAS high. Give your systems some elbow room and watch them fly!

Adding yet more limits on memory usage by cluttering APIs with more options is absolutely the WRONG way to go. All it will do is litter your procedures with assumptions reflecting TODAYs resource costs. Ultimately this will negatively impact performance by artificially constraining resource consumption.

Most people want things to go faster and faster as resource availability increases. If you really want to, you can set values down. There's nothing to stop you from doing that, but it's swimming against the tide and shouldn't be the default.

[Wim Van den Wyngaert]

John,

Then why do we still have the values in the SYSUAF ? Almost none of the limits arrive without being corrected.

I don't have a problem with SORT but I have a problem that if you change e.g. wsextent that this has influences that have nothing to do with it. E.g. Increase your wsextent because only processes that do PF get extra memory and what do you see : sort takes it in a split second.

But this was not the subject.

My questions was : are there any other programs that set their working set size to a value above wsquota ?

E.g. SYBASE servers have very big quota's but they react properly.

[Lawrence Czlapinski]

Wim, I agree that AUTOGENs default of setting PQL_DWSEXTENT AND PQL_MWSEXTENT TO WSMAX can cause undesirable memory behavior.
As you pointed a program like SORT can hog the memory to the detriment of other higher level processes. Unfortunately, to set PQL_DWSEXTENT and PQL_MWSEXTENT lower in AUTOGEN, one has to set a MAX_PQL_DWSEXTENT and a MAX_PQL_MWSEXTENT.
John,
1. If there is an abundance of physical memory, high PQL_MWSEXTENT is fine.
2. If memory usage gets close to 100%, low priority processes can grab the memory first and cause higher priority processes to page fault more. The SORT program, DEC Windows processes, BACKUP or other low priority processes can grab memory that could otherwise go to other higher level processes that are above WSQUOTA.
3. On some disks, disk space get tight. For our customer, IT is an expense. It doesn't make money. There has to be sufficient justification for any improvements. And even if you convince the local customer that doesn't mean that a customer can get request for improvements approved by higher levels of the company. In most companies, disks tending to fill to capacity is not sufficient justification for getting larger disks. However, memory a process uses above WSQUOTA is physical memory not VM.
4. I still have 13 VAXes which is an improvement from where we were. We have migrated some clusters/systems to Alphas. I have VAXes: 1 with 36 MB, 1 with 40 MB, 10 with 64 MB and 1 with 128 MB. Most PCs in use do not have 500 MB of memory.

[John Gillings]

Wim,

>Then why do we still have the values
>in the SYSUAF ? Almost none of the
>limits arrive without being corrected.

You have UAF limits to manage resources on a per-user basis. Out of the box the only UAF quotas that is likely to be overridden are WSEXTENT, WSQUOTA and WSDEFAULT. These (and the PQL_D equivalents) are the only PQL SYSGEN parameters that AUTOGEN sets. In general, the WSDEFAULT and WSQUOTA values chosen by AUTOGEN are too low to override your UAF values - the reason for setting them has to do with "autotuning memory management" introduced in VMS V5.4-3. In practice, it's only WSEXTENT that anyone is likely to notice.

If you find you have other UAF values being overridden, it's either another product or your own values in MODPARAMS.

The WSEXTENT values chosen by AUTOGEN are a reflection of the changes in typical resources available today. When memory was very expensive, the complex working set management logic was reasonable. Today it isn't necessary, so we've effectively removed the need for system managers to worry about micro managing process WSEXTENTs.

This is NOT compulsory! Should you choose to, simply override the AUTOGEN setting of PQL_MWSEXTENT in MODPARAMS:

MAX_PQL_MWSEXTENT = 2048 ! (default default)

The only thing you really need to worry about is that PGFLQUOTA is higher than WSEXTENT, and that page files are large enough to support your total virtual address space loading.

Lawrence,

Some of the changes in default behaviour may be detrimental to systems with lower levels of resource, especially when they're pushed to their resource limits. But it's unreasonable to impose unnecessarily restrictive defaults on the majority to benefit the minority. If you're stuck with systems with small memories and lack of disk space, you'll need to put in some effort to manage your limitations.

Remember, AUTOGEN is intended to be a *starting* point, not a definitive optimal tune for your exact environment.

> For our customer, IT is an expense.
>It doesn't make money. There has to
>be sufficient justification for any
>improvements.

Certainly true, but when I see someone spend several hours scabbling around to recover a few hundred MB of disk space, I think of how much that human time has cost, vs the real cost of that disk space. If a lack of resource has caused system down time then the expense to the business could be a lot of orders of magnitude over the cost of the disk space that may have prevented the downtime in the first place!

Your management probably has no problem justifying spending recurrent money on insuring against (say) fire damage, but they won't spend a few hundred bucks "one off premium" to buy a disk to make your page file large enough to *eliminate* page file hangs? (granted there may be complicating factors like availability and cost of compatible hardware and/or physical expansion limits, but the point is, I see so many cases where the *true* relative costs are ignored. A few dollars wisely invested can save a furtune!)

[Lawrence Czlapinski]

John,
1. Having a high PQL_MWSEXTENT (minimum WSEXTENT)as a default does make sense since it usually isn't a problem.
2. It can become a problem when a system gets close to 100% of memory usage. Memory usage often tends to grow over time as more tasks are added. In cases where memory usage is close to 100% on a system that has a lot of processes running, a high minimum WSEXTENT can cause excessive hard page faulting.
As both you and I said, a sys admin can override PQL_MWSEXTENT if desired, by setting MAX_PQL_MWSEXTENT and possibly MAX_PQL_DWSEXTENT in MODPARAMS.DAT.

"Swapping can be induced whenever one or a small number of processes devour memory at the expense of other processes. You can find out if a few users are using large amounts of memory by examing the display produced by the MONITOR PROCESSES command. ... Large, Compute-Bound Process Gain Inordinate Control of Memory" from Guide to OpenVMS Performance Mangement.

A high PQL_MWSEXTENT does allows memory hog processes such as Oracle and DECW$* processes tend to gobble up lots of memory above WSQUOTA on a first come first serve basis. On a VAX with a small amount of memory, a high PQL_MWSEXTENT can even cause a low priority BACKUP to hog memory.

3. PGFLQUOTA is another issue. For me, AUTOGEN has sized pagefiles large enough for our 22 systems. Yes, sometimes it would make more sense to spend money for larger disks. Usually, the money for time comes out of a different cost center than disk expenditures. Expenditures for larger disks have to compete with other budget requests in the department and in the company. We have been fortunate to have upgraded some more VAXes to Alphas in 4 QTR 2004. And the faster VAXes were redeployed to replace slower VAXes. Limited disk space could be another reason that a sys admin might want to lower PQL_MWSQUOTA. I don't currently have page file size problems on my 22 systems. The applications and developers tend to fill up the disks no matter how large the disks.
Lawrence