|
HP OpenVMS Systemsask the wizard |
|
The Question is:
My database will not come up after increasing
the number of GBLPAGES to be used. I am using
Ingres 6.4 DBMS and have the following:
VAX/VMS V6.2 7630 (1 Gig Memory):
GBLPAGES 750000 15000 512 4194176 Pages
GBLSECTIONS 3072 250 60 4095 Sections
GBLPAGFIL 150000 1024 128 4194176 Pages
591 Global Sections Used, 198722/551278 Global Pages Used/Unused
I use the run command to start a detached
process. I want to start three DBMS servers
that will use a single shared_cahce to hold
the DBMS working pages. I set the
/extent=150,000 (WSMAX=150,000)
/working_set=100,000
/maximum_working_set=80,000
(I read that the larges value for the
last two is 64K, it gets truncated)
There is a switch for the DBMS to allowcate
shared_cache in global memory. It is in
Ingres pages (4 VMS pages = 1 Ingres page)
/DMF=(/read_ahead=32, read_cnt=100,
cache_size = 20000)
This should set aside 92,800 VMS GBLPAGES.
?Question?
1) Is the global pages (section, files) at
all dependent on the Working Set settings?
If so, how?
2) Using the above settings, the DBMS process
comes up running. If I increase the
Cache_size=40000, the DBMS process does not
get created. There should be enough memory
(GBL) correct?
3)Can you quickly show how GBLPAGES,
GBLSECTIONS, & GBLPAGFIL are related?
4) Is the account's process settings (WS, etc)
that creates the detached independent of the
detached process if the above switches are used?
The Answer is :
0: The Wizard strongly recommends contacting the folks at Ingres
support for assistance with resolving an Ingres database problem.
1: No. Working set sizes only control how much virtual memory may be
in physical memory simultaneously for one process only. Global pages
are not charged against the working set.
2: Not necessarily. Depending on the exact nature of the global cache
(since the Wizard is not familiar with this data base, this is a best
guess), it's likely that the global pages used must be contiguous.
It is quite possible that even with 550000 free GBLPAGES, the largest
contiguous block is smaller than 200000 -- much like disk storage,
it is possible for global page tables to become fragmented. Use the
lexical function F$GETSYI("CONTIG_GBLPAGES") to find out:
$ WRITE SYS$OUTPUT F$GETSYI("CONTIG_GBLPAGES")
142362
If the cache is backed to the page file, the most likely explanation
is that your GBLPAGFIL parameter is much too low.
3: In short, they are not related.
GBLSECTIONS controls how many global sections can exist on a system
simultaneously. It is independent of the size of the sections. So a
large number of small sections may take less GBLPAGES than a small
number of large sections. The parameter is cheap, so aim for at least
30% free at all times. In practice free sections are usually higher
and, in the wizard's experience, problems due to insufficient global
sections are very rare.
GBLPAGES is the total number of pages in all global sections. In
addition to considering the raw number of pages, you should also
consider fragmentation, especially when dealing with large sections.
There is also the issue of life time. Remember that deleting or
replacing a global section is not necessarily synchronous, so, if you
need to replace a particular section frequently, make sure you have
sufficient pages for 2, or maybe even 3 CONTIGUOUS copies of the same
section. In your case you want a section of around 180000 pages. If you
want to be able to recreate it, I'd suggest allocating 600000 (or more)
pages for that purpose. GBLPAGES are cheap, but not free. They cost 4
bytes of physically resident memory for every 128 pages, so your 600000
pages would cost 12.5Kbytes. Problems due to insufficient absolute or
contiguous GBLPAGES are relatively common. Aim for at least 20% free at
all times. When playing with large sections, go for 50-60% free. You
can determine your peak usage from AUTOGEN:
$ @SYS$UPDATE:AUTOGEN SAVPARAMS SAVPARAMS ! Record feedback data
$ SEARCH SYS$SYSTEM:AGEN$FEEDBACK.DAT GBLPAGES
GBLPAGES_CUR = 250000
GBLPAGES_PEAK = 107262
GBLPAGFIL is a "blade guard". Whenever virtual memory is created, it
must be given a "backing store" (that is, somewhere to put the pages
when they are not in physical memory). For a global section, the store
may be an ordinary disk file, but it may also be the paging file. The
choice is made when the section is created. Since the lifetime of a
particular global section may be longer than that of the process which
creates it, it is not possible to "charge" the page file usage of a page
file backed global section against the quota of the creator. On the
other hand, the pagefile usage must have some sort of quota, otherwise
a nonprivileged user could consume all available pagefile space simply
by creating a large enough global section. So, GBLPAGFIL is like a
system wide PGFLQUOTA for pagefile backed global sections. In setting
it remember that RMS global buffers must be counted, and the general
rule of thumb is to keep pagefiles at least 50% free. If your section
is pagefile backed (which is likely), you need to allocate at least
200000 pages for it, plus any other requirements. Also remember that if
section replacement is asynchronous, you may need allocation for 2.
So, I'd suggest you start with GBLPAGFIL=550000. Just make sure you
have sufficient page file that a user accidently or deliberately
consuming all of GBLPAGFIL won't deplete your page file enough to hang
your system. You can check your remaining of GBLPAGFIL in SDA:
$ ANALYZE/SYSTEM
EXAMINE MMG$GL_GBLPAGFIL
MMG$GL_GBLPAGFIL: 00006A01 ".j.."
EVALUATE 00006A01 ! convert to decimal
Hex = 00006A01 Decimal = 27137
As of OpenVMS V7.1, GBLPAGFIL is a dynamic parameter. On prior versions
changing it required a reboot (though you may be able to locate hacks
around the web with which you could raise it dynamically, just don't
complain to the wizard if you crash your system using it!).
4: Given sufficient privilege (IMPERSONATE, as the DETACH privilege
is now known) you may give a detached process a higher quota than the
creator process. Without privilege, you are limited to the quotas of
the creator.
The Wizard suspects that your problem is simply that the GBLPAGFIL
setting is too low.
|