[Info-vax] SOLVED : Re: Process quota problem after upgrade to 8.4-2L1

[Dave Froble]

On 12/22/2020 10:22 AM, Stephen Hoffman wrote:
> On 2020-12-22 11:07:19 +0000, Joukj said:
>
>> Stephen Hoffman wrote:
>>>
>>> Check the PQL minimum parameter settings, check the current SYSTEM
>>> quotas from a fresh OpenVMS install and also check those quotas
>>> against current DECwindows requirements, and then failing that
>>> incrementally double each of the pooled process quotas (BYTLM, ENQLM,
>>> FILLM, PGFLQUOTA, PRCLM, TQELM) until it starts working again.
>>>
>>> OpenVMS upgrades and DECwindows upgrades don't raise user quotas to
>>> any newly-applied minimums that might have gotten shipped.
>>>
>>> ~Forty years in, we're also prolly not going to see better logging
>>> implemented within $creprc, or see $creprc switching to the
>>> long-available quota-specific errors due to "compatibility", either.
>>>
>> Thanks Hoff, You pointed me to the Right solution: Doubling all the
>> pql_m* parameters did not help. But setting PQL_MPGFLQUOTA to 18000000
>> (may be too high but set the same as for "user" system) did the trick.
>> So also Tad's suggestion was correct. It wer the pagefile-quota.
>
> Ah, I meant keep doubling the quotas and the PQLs until it works, and
> not to double the settings just once. And for cases such as this, it's
> usually involving a pooled quota.
>
> Something within OpenVMS and/or DECwindows here either isn't specifying
> quotas, or isn't specifying sufficient quotas. Which has happened
> before. There was an annoying DECwindows quota bug a while back, where a
> low quota was detected, but the quota-increasing code, well, didn't. So
> the low-quota triggered again. Lather, rinse, repeat.)
>
> SYSTEM quotas have been increased once or twice before too, and may well
> need another increase. IIRC, those quota increases were not applied to
> existing SYSTEM usernames, just to newly-created ones.
>
> I can guarantee you that there are stale quota listings in various parts
> of the OpenVMS docs too, and the older the docs the staler the settings.
> Not unless VSI has implemented a feedback connection between the testing
> environment and the doc. Which has been discussed, but I'd doubt exists.
> And most of us are working with more memory and more storage than
> before. Most of us only look at quotas when something blows up, and very
> few watch quota usage trends.
>
> Cluster satellite workstations are also not configurations I'd expect to
> see a whole lot of usage or testing, generally. I'd expect little usage
> of these configurations outside of hobbyist environments. We'd see yet
> fewer of these cases too, if OpenVMS were better about its installation
> and re-installation and provisioning and which would ease cloning in
> combination with better LDAP support—storage is cheap, network-served
> system storage is slow, and few (~nobody?) is running 10 GbE or 40 GbE
> satellites.
>
> Years ago, I wrote some code that detected and automatically increased
> quotas on all users of an environment to established minimum values, and
> that solved a large number of weird problems within the environment.
> Nowadays, I prefer to combine that app quota startup check with a C
> run-time settings startup check. But establishing new minimum quotas was
> still a manual process, even if then raising the users' settings was
> automatic.
>
> Here's a question for each of us to ponder for our own environments:
> when was the last time that a quota check actually prevented a wider
> hang in our local environments, rather than triggering a failure? Most
> of us have seen run-away leaks, but how many have seen one of those app
> leaks then cause system-wide effects rather than blowing out whatever
> the leaking app was? Are our possibly-too-low-quota settings even worth it?
>
>

A long time ago when I was first working with detached processes I ran 
into problems with the PQL quotas.  Since then, I've always considered 
them suspect when problems arise.

Quotas come from a bygone era when system resources were rather limited. 
  While I would not just get rid of the concept, since it does allow 
customization in the few cases where it is needed.

I'm not much of a fan of just setting quotas to a gazillion and figure 
the problem is solved.  That can be interesting.  I remember the case 
where a user set the WSDEF to some high number, then complained because 
process startup was so slow, while the system attempted to scrounge 
enough memory to meet the WSDEF.  (It was WSEXTENT that he should have 
changed.)

I'd welcome some guidelines from VSI on reasonable quotas for today's 
systems.  Hope that's not too much to hope for.  A utility for updating 
to recommended minimums would be even better.

As mentioned, existing account information is not changed in an upgrade. 
  That leads to the dark side, sooner or later.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486