Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

ridiculous GBLPAGES Autogen values under VMS 7.2-2

Jess Goodman
Esteemed Contributor

ridiculous GBLPAGES Autogen values under VMS 7.2-2

When I have upgraded an Alpha from VMS 7.2-1 to VMS 7.2-2 AUTOGEN insists on setting GBLPAGES to ridiculously high values, higher than the amount of system memory.

The following is from AGEN$PARAMS.REPORT on an AS4100 with system memory of 2GB (4194304 pagelets).

GBLPAGES parameter information:
- AUTOGEN parameter calculation has been overridden.
The calculated value was 50397698. The value 50452146 will be used in accordance with the following requirements:
GBLPAGES has been increased by 54448.
GBLPAGES minimum value is 150000.

If I run AUTOGEN later with feedback it doesn't reduce it; it increases it more:

GBLPAGES parameter information:
Feedback information. Old value was 50452146, New value is 50577907
Maximum used GBLPAGES: 205216
Global buffer requirements: 3145728
Pagelets reserved for memory resident sections: 0

Does it hurt anything (i.e. waste memory) to leave GBLPAGES set so high? Should I manually set it to a reasonable number after every AUTOGEN?

I have one, but it's personal.
10 REPLIES
Andy Bustamante
Honored Contributor

Re: ridiculous GBLPAGES Autogen values under VMS 7.2-2

The wizard says: http://h71000.www7.hp.com/wizard/wiz_7752.html

This change started in 7.3 (7.2-2 is a later release than 7.3). I used to have to force GBLPAGES higher for my application.

The memory used isn't going to be significant and, if you have an application using global pages, tuning is required less frequently.
If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Edwin Gersbach_2
Valued Contributor

Re: ridiculous GBLPAGES Autogen values under VMS 7.2-2

See the following article for a explanation:

http://h71000.www7.hp.com/wizard/wiz_7752.html

Edwin
Wim Van den Wyngaert
Honored Contributor

Re: ridiculous GBLPAGES Autogen values under VMS 7.2-2

On my GS160, only 4% of the GBL entries are used. But suppose the remaining 70 M pages were requested by a program. 38 GB would then be required. Wonder what would happen.

As I see it, this means that the limit has been removed and you no longer have protection against a program eating them all. Just as in Unix.

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: ridiculous GBLPAGES Autogen values under VMS 7.2-2

Is there anyone with a 7.3(+) node on which a significant portion of gblpages is used ?

I consider putting GBLPAGES= in modparams to deactivate this "no limit".

Wim
Wim
Ian Miller.
Honored Contributor

Re: ridiculous GBLPAGES Autogen values under VMS 7.2-2

You can limit this with
MAX_GBLPAGES=
in MODPARAMS.DAT


____________________
Purely Personal Opinion
Wim Van den Wyngaert
Honored Contributor

Re: ridiculous GBLPAGES Autogen values under VMS 7.2-2

And let autogen decrease it ? (I know, it will not in current versions)

A system manager should setup a good value and change it when it is to small.
I already set fixed values for the number of processes and others. Doing an autogen after something went wrong (e.g. a few hundred processes created "by accident") may lead to a misconfigured system. I also have to be drp ready, thus autogen may not base the value on what he saw.

Wim
Wim
Robert_Boyd
Respected Contributor

Re: ridiculous GBLPAGES Autogen values under VMS 7.2-2

you might look through the report and take notice of all the file names that are being used as input. Are there AGEN$INCLUDE files?
What about what is coming from PARAMS.DAT or other files that are behind the scenes? Do any of these files have entries of ADD_GBLPAGES?

There's a good chance that it's time to remove the ADD_GBLPAGES entries and change to MIN_GBLPAGES for good measure

Robert
Master you were right about 1 thing -- the negotiations were SHORT!
Wim Van den Wyngaert
Honored Contributor

Re: ridiculous GBLPAGES Autogen values under VMS 7.2-2

Robert,

My MIN_ is 4 GB which is 3 times the amount we need. But the MIN_ coming from autogen itself is 36 GB. So, whatever you ask, the MIN_ from autogen is higher.

That's why I consider a fixed GBLPAGES (which usage we monitor : alarm when 40% used
while not in DRP mode, which is running the cluster on 1 node).

Wim
Wim
Cass Witkowski
Trusted Contributor

Re: ridiculous GBLPAGES Autogen values under VMS 7.2-2

There was a problem with autogen calculating gblpages. If I recall correctly it had to do with the fact that it set GBLPAGFIL to 3/4 of memory and then thinking that GBLPAGFIL was pagelets and not pages.

You end up with a value that is greater than the physical amount of memory on your machine. This is fixed in V7.3 or later of OpenVMS

Regards

Cass
John Gillings
Honored Contributor

Re: ridiculous GBLPAGES Autogen values under VMS 7.2-2

Jess, please recalibrate your definition of "reasonable" & rediculous to current resource levels!

This is intended behaviour. By default, AUTOGEN will set GBLPAGES to 3/4 of physical memory. On VAX, the cost of GBLPAGES was 4 bytes of physically resident memory for every 128 global pages, but that's no longer an issue on Alpha.

Alpha page table entries are 8 bytes, one per global page, but the page table pages themselves are in virtual memory - S2 space, and initially demand zero (so they don't actually exist). All that's needed are the system page table pages required to map the global page table. For GBLPAGES set to 3/4 of total physical memory, that's a bit less than 1 millionth of physical memory. In other words, the "penalty" for a high value of GBLPAGES is negligible if you don't use them.

This deliberate change to AUTOGEN is intended to encourage the use of RMS global buffers. So, if you're NOT using a significant proportion of GBLPAGES, you should be turning on global buffers and reaping the performance reward (remember, as Hein says, there is only ONE WRONG number of global buffers on an RMS file - ZERO!).

On the other hand, both GBLPAGES and GBLPAGFIL are dynamic, so feel free to adjust them up or down whenever you like.
A crucible of informative mistakes