 |
The Question is:
We are experiencing periodic failures of calls to sys$mgblsc when attempting to
map a large global section, or with subsequent mapping of a much smaller
global section. The error being returned is 284; insufficient working set
limit. The account being use
d has WSQUO, WSEXT and PGFLQUO set to 4,000,000. The WSMAX system parameter is
set to 5,000,000. The size of the region we are trying to map is 1,042,287
pagelets. These failures often go away with a retry; actually, the process is
restarted because it di
es on the map failure. When the process succeeds, monitor shows a working set
size of 66,136 with 86,874 virtual pages used.
I'm thinking the problem may be related to one, or all of the following
parameters and current values:
PAGEDYN 7,168,000
NPAGEDYN 10,592,256
NPAGEVIR 52,961,280
Am I right, or am I heading down the yellow brick road?
The Answer is :
WSMAX and the process pagefile quotas are usually the central issue,
as is the virtual address space of the running image as limited by
the available system virtual address space. (On OpenVMS Alpha V7 and
later, the VIRTUALPAGECNT setting is usually not a factor.) Also
involved as a factor is the amount of physical memory presently free,
and also determine if the MINWSCNT value is set to an unusual value.
Having the default, quota and extent quotas set to the same value is
unusual and not recommended.
PAGEDYN and NPAGEDYN are not particularly related to the working set.
If the application is running detached, make certain to specify the
complete process quota list on the RUN/DETACH or $creprc command.
Related topics include (7876).
Also please consider using sixty-four bit virtual address space. (That
is not an immediate solution to the process working set sizing, however.)
|
