Consultor Eletrônico

The following information has been taken from the 8.1A03 release notes for VAX and Alpha OpenVMS. (readme.pro)

6. PROGRESS USAGE OF OpenVMS RESOURCES

The following sections are designed to assist you in understanding what kind of OpenVMS system and process level resources PROGRESS requires in order to perform on your system. These are only guidelines and some hints.

6.1 PROGRESS Usage of OpenVMS System Level Resources

OpenVMS system resources are those controlled by the SYSGEN utility.
PROGRESS generally only uses system level resources for sharing data
between multiple users. In particular, PROGRESS makes heavy use of
globally mapped system pages (GBLPAGES and GBLPAGFIL). As you increase the number of servers and clients to your PROGRESS, RMS, or Oracle databases, the system will require more resources in order to efficiently access the database. In addition, the GBLPAGFIL parameter will get used heavily if you use the RMS dataserver. See the SYSGEN utility help for these parameters for the details as to how they are used.

Each server to a database takes one OpenVMS process slot and each client accessing the database will also take an OpenVMS process slot. Process slots are controlled by the MAXPROCESSCNT and BALSETCNT parameters. In addition, in order to ensure that your processes get the most out of the system, you will need to modify the WSMAX and VIRTUALPAGECNT. These parameters dictate how much physical memory a process can have and how many pages in the system page file may be mapped by the process.

If you are unsure how to handle system parameters, use the OpenVMS
AUTOGEN utility with FEEDBACK on a fairly regular basis during heavy
user loads on your system. This utility will help set your system
parameters based on usage it has osbserved. See the OpenVMS System
Managers documentation set for details on using AUTOGEN.

Beyond memory resources, as you increase the number of servers and
clients accessing the system, the demand for CPU and I/O resources
will also be increased. You should periodically do some sort of
capacity planning in order to ensure you are getting the most out of
the system. As you add servers and clients they will begin competing
for the same CPU(s). I/O contention will increase if all your PROGRESS files reside on one disk. Additionally, keeping PROGRESS on your system disk will also make PROGRESS compete for I/O resources with other system operations.

The following section describes the main PROGRESS resource used, GBLPAGES. When starting a Multi User session, the first PROGRESS server creates a Disk Mapped Global Section for backing store for each database to which you have a server connected. This operation requires the use of disk space and system global pages in order to allow other servers and clients to map the same section file. The amount of resources required for this operation depends mainly upon the parameters used to start the server. Specifically the numbers used in the following qualifiers will have an effect on the resources (see the PROGRESS System Adminstration Reference Guide for details on how to use the parameters).

VMS Qualifier UNIX Equivalent Default Value
---------------------------------------------------------------------
/BUFFERS -B 160 [-n * 8]
/TOTAL_PRIVATE_BUFFERS -I 40 [-n * 2]
/HASH -hash 43 [-B / 4] (1)
/BIBUFFERS -bibuf 5
/AIBUFFERS -aibuf 1
/NUMBER_OF_USERS -n 20
/MAXSERVERS -Mn 4
/LOCK_TABLE -L 500
/LKHASH -lkhash 83 [-L / 8] (2)
/EXCESS_SHARED_MEMORY -Mxs 22384 [ 16384 + (300 * -n) ]

(1) -hash is a prime number greater than 1/4 the -B value where the prime number is sourced from an internal PROGRESS array from 13 to 98407

(2) -lkhash is a prime number greater than 1/8 the -L value where the prime number is sourced from an internal PROGRESS array from 13 to 98407

The following equation will give you a rough guess as to how much
resources will be required based on the parameters selected. Note that the actual may be more or less that your calculated value, since the values listed are rounded to the nearest tenth, thus you should always leave room for slight error in calculation. In addition, Alpha systems tend to take more space due to alignment issues. The following formula uses the UNIX syntax to determine the value, this was done to save space.

18000 + (-Mxs) + ( -Mn * 90) + ((-Mn + -n) * 624) + ((-Mn + -n) * 20) + ((-B + -I + 2) * 144) + (-hash * 4) + ((-B + -I + 2) * 1030) +
(2 * (20 * (-Mn + -n) + 28)) + (-bibufs * 176) + (-bibufs * 16388) +
(-aibufs * 160) + (-aibufs * 16388) + (-lkhash * 12) + (-L * 20)

Therefore, using the default values:

18000 + 22384 + (4 * 90) + ((4 + 20) * 624) + ((4 + 20) * 20) +
((160 + 40 + 2) * 144) + (43 * 4) + ((160 + 40 + 2) * 1030) +
(2 * (20 * (4 + 20) + 28)) + (5 * 176) + (5 * 16388) +
(1 * 160) + (1 * 16388) + (83 * 12) + (500 * 20)

The approximate default default size is : 426980 bytes or 834 pages.

Depending on how many database servers you have running, you will need
at least this calculated value for each database. Once the database
has a server mapping to the database .SHM file, each other server and
client will only need to map this many pages.


6.2 PROGRESS Usage of OpenVMS Process Level Resources

To understand OpenVMS usage of process resources, you should read the
OpenVMS System Managers Guide. There is a very detailed description of
how OpenVMS uses process resources. In particular, it is important to
understand how memory is allocated to the process and what happens when the process reaches its working set quota.

In terms of the authorized quotas for an account, the important
parameters for process memory are WSDEF (working set default), WSQUOTA (working set quota), and WSEXTENT (working set extent). In addition, the process page file quota (PGFLQUO) is used to determine how many pages of memory the process is allowed to use in the page file.

In general, PROGRESS is a heavy user of OpenVMS process resources. In
particular, PROGRESS uses a great deal of process memory. The PROGRESS images tend to be large. Each image must be loaded into the process' memory space. Portions of the image not used are eventually paged out of the process' physical memory into a section of the system page file which the process is using.

During a normal VMS session, a process will work to keep it's working
set around the value of WSQUO. If there is free memory in the system,
the process can then allocate up to WSEXTENT pages of physical memory
for its usage. However, if the system finds memory being over utilized, those processes which are over quota will begin to get "trimmed back" to the WSQUO value so that other processes that also need the memory will also be able to access the memory. Those pages that are trimmed back are paged out.

PROGRESS Client sessions on OpenVMS systems tend to use between 10,000
and 15,000 pages of working set just to get to the PROGRESS Editor.
Thus, in order to keep the entire image in memory, the working set quota for the account could be set to 16,382. Although, this value can vary depending on startup parameters and operations performed.

PROGRESS Server sessions on OpenVMS systems tend to use between 8,000
and 12,000 pages of working set just to get the server running. Thus,
in order to keep the entire process in memory, the working set quota
for the account could be set to 16,382. Again, this value fluctuates
depending on startup parameters for the server.


6.3 Tools to Help Monitor

OpenVMS provides two basic tools to help monitor the activity on your
system. The first is the Monitor utility, which gives you a character
cell interface to view how your system is currently performing. This
utility is included on every VMS system and is invoked via the DCL
command, MONITOR. The MONITOR utility is well documented in the OpenVMS System Managers documentation set. The second tool is DECamds, which must be installed and is free to those that have a VAXcluster, VMScluster-Client, or VMScluster license. DECamds uses a DECwindows Motif interface to provide a similar view of system performance as well as an event system to point out where resources are being over utilized. DECamds is distributed with the OpenVMS operating system distribution kit and has it's own User's Guide.

Beyond the free tools, Digital also sells Polycenter Performance
Solutions which is a comprehensive set of tools to give performance and capacity style information and suggestions. There are also a number of Digital's 3rd party vendors which also sell performance solutions.