Before you undertake any action, you must recognize that the following sources of performance problems cannot be cured by adjusting system values:
When you make adjustments, you normally select a very small number of values for change, based on a careful analysis of the behavior you observed. You control system resources by tuning the values of two types of parameters:
Parameter Type | Description |
---|---|
System parameters |
The values set for system parameters control system resources on a
systemwide basis. The AUTOGEN command procedure automatically sets
system parameters to appropriate values for your system configuration.
AUTOGEN can also record feedback from a running system to adjust those
parameters based on the system's work load.
The OpenVMS Performance Management describes how to select the parameters and new values that are likely to produce the desired changes. Section 14.5 explains how to use AUTOGEN to modify system parameter values. |
UAF limits and quotas | The values set for limits and quotas in each user authorization file (UAF) record control system resources on a per-user basis. To control these values, use the Authorize utility. For information, see Section 6.11. |
Before you undertake any tuning operation, be sure you are familiar with the resource management mechanisms described in the OpenVMS Performance Management. Understand the nature of system values before adjusting them. Without the proper level of understanding, you might degrade, rather than improve, overall performance.
Under most conditions, tuning is rarely required for OpenVMS systems. The AUTOGEN command procedure, which is included in the operating system, establishes initial values for all the configuration-dependent system parameters so that they match your particular configuration. For information about AUTOGEN, see Section 14.4.
Additionally, the system includes features that, in a limited way, permit it to adjust itself dynamically during operation. That is, the system detects the need for adjustment in certain areas, such as the nonpaged dynamic pool, the working set size, and the number of pages on the free and modified page lists. The system makes rough adjustments in these areas automatically. As a result, these areas can grow dynamically, as appropriate, during normal operation.
Experience has shown that the most common cause of disappointment in system performance is insufficient hardware capacity. Once the demand on a system exceeds its capacity, adjusting system values will not result in any significant improvements, simply because such adjustments are a means of trading off or juggling existing resources.
Although tuning is rarely required, you should recognize that system tuning may be needed under the following conditions:
Whenever you adjust your system, you should monitor its behavior afterward to be sure that you have obtained the desired results. To observe results, use the Monitor utility and the various forms of the DCL command SHOW. See the OpenVMS DCL Dictionary for detailed information on the SHOW command. See Section 18.8.2 for information about using MONITOR. See the OpenVMS System Management Utilities Reference Manual for detailed descriptions of MONITOR commands.
For example, you might consider running some programs (whose results you believe are fixed and reproducible) at the same time that you run your normal work load. If you run the programs and measure their running times under nearly identical work load conditions both before and after your adjustments, you can obtain a basis for comparison.
However, when applying this technique, remember to take the measurements under very similar work load conditions. Also, remember that this test alone does not provide conclusive proof of success. The possibility always exists that your adjustments may have favored the performance of the image you are measuring---to the detriment of other images. Therefore, in all cases, continue to observe system behavior closely for a time after you make any changes.
Following is a list of optional system management operations, normally performed after installation, that often result in improved overall performance. Choose the options that are appropriate for your site. Not all options are appropriate at every site.
SET VOLUME/NOHIGHWATER_MARKING device-name[:]
The Install utility (INSTALL) stores information about images in memory. Use INSTALL for the following reasons:
Reason | For More Information |
---|---|
To conserve memory use for images that are used concurrently | Section 16.9.7 |
To improve system performance | Section 16.9.5 |
++On Alpha systems, with resident images to improve performance | Section 16.9.6 |
To make executable images that require enhanced privileges available for general use | Section 16.9.8.1 |
To allow a nonprivileged image to call the privileged functions of a shareable image | Section 16.9.8.2 |
To mark a sharable image as trusted so it can be invoked by privileged executable images | Section 16.9.9 |
The site-independent startup command procedure, STARTUP.COM, uses INSTALL to install certain system images when the system boots. You use INSTALL to install other selected images, according to the needs of your site.
Installed images must be reinstalled each time the system reboots. To do so, include INSTALL commands in the site-specific startup command procedure SYSTARTUP_VMS.COM, as explained in Section 5.2.7.
The Install utility (INSTALL) only installs images that are linked with the /NOTRACEBACK qualifier.
Note that INSTALL commands perform a different function than System Generation utility (SYSGEN) INSTALL commands.
The following sections explain installed images and how to use the Install utility.
An image is a collection of procedures and data bound together by the Linker utility. Executable images can be executed (or run) in a process, either by a command line interpreter (CLI) or the $CREPRC system service. Usually, executable programs have the file type .EXE.
There are three types of images:
Image Type | Description |
---|---|
Executable | An image linked with the /EXECUTABLE qualifier (or without the /SHAREABLE qualifier) of the Linker utility. For more information, see the OpenVMS Linker Utility Manual. |
Shareable | An image linked with the /SHAREABLE qualifier of the Linker utility. Shareable images are sometimes referred to as linkable images, because they can be specified---implicitly or explicitly---as input files to the link of another file. A shareable image is not copied into the executable images that link with it. Thus, only one copy of the shareable image needs to be on disk, no matter how many executable images have linked with it. For more information, see the OpenVMS Linker Utility Manual. |
System | An image that does not run under the control of the operating system. It is intended for standalone operation only. The content and format of a system image differs from that of shareable images and executable images. For more information, see the OpenVMS Linker Utility Manual. |
When you install an image with INSTALL, the image is assigned attributes and becomes known to the system. For this reason, an installed image is also called a known image.
The image activator processes search lists in two passes, in order to favor known images. On its first pass through the search list, the image activator looks up images as known files. If needed, on a second pass through the search list, the image activator looks up images on disk.
The system defines known images in internal data structures called known file entries. Each entry identifies the file name of the installed image and the attributes with which it was installed (for information about attributes of installed images, see Section 16.9.3).
Known file entries last only while the system is operating. If the system is shut down or fails for any reason, you must reinstall all known images after the system is rebooted.
By specifying appropriate qualifiers to INSTALL commands, you can assign attributes to known images. Table 16-1 describes these attributes and the qualifiers that are used to assign them to known images.
Attribute | Description | Qualifier |
---|---|---|
Header resident | The header of the image file (native images only) remains permanently resident, saving one disk I/O operation per file access. For images with single-block file headers, the cost is less than 512 bytes of paged dynamic memory per file; for images with multiblock headers, the cost varies according to the header block count. Images installed header resident are implicitly installed permanently open. | /[NO]HEADER_RESIDENT |
Permanently open | The image file remains open, so access to the image does not require a call to the file system. | /OPEN |
Privileged | Amplified privileges are temporarily assigned to any process running the image, permitting the process to exceed its user authorization file (UAF) privilege restrictions during execution of the image. In this way, users with normal privileges can run programs that require higher-than-normal privileges. This attribute (and the /PRIVILEGED qualifier that creates it) applies only to executable images. | /PRIVILEGED[=(priv-name[,...])] |
Protected | When the image is activated, the address space for the image is protected against modification by user-mode code. This is critical for shareable code that runs in kernel or executive mode. | /PROTECTED |
++ Resident | On Alpha systems, code or read-only data for an image is made permanently resident in a system region of memory. This improves performance by using a special page mapping to reduce tranlation buffer (TB) miss rates. The resident attribute applies to shareable or executable images that have been linked with the qualifier /SECTION_BINDING=(CODE,DATA). For more information, see Section 16.9.6. | /RESIDENT |
Shared | More than one user can access the read-only and non-copy-on-reference read/write sections of the image concurrently, so that only one copy of those sections needs to be in physical memory. (Copy-on-reference sections always require a separate copy for each process.) The image is implicitly declared permanently open. | /SHARED |
Writable | When a shareable non-copy-on-reference writable section is removed from physical memory (for paging reasons or because no processes are referencing it), it is written back to the image file. Any updates made by processes mapped to the section, therefore, are preserved (while the initial values are lost). The image must also be declared shareable. | /WRITABLE |
You can install images to do the following:
Because an installed file requires system resources, such as paged dynamic memory, install those files that most improve system performance and site requirements. The INSTALL command LIST provides information about installed images to help you evaluate the merits of installing images. For example, the LIST command calculates the number of times each image is accessed, and shows the number of concurrent accesses, so you can determine if the installation of the images is worth the overhead.
You can improve image activation performance by installing images that run frequently. Image activation performance improves when programs are installed because the operating system opens installed files by file ID rather than by file name, thus eliminating costly directory operations.
Installing images as header resident further enhances activation performance because the system avoids the overhead of I/O operations to read the image header into memory.
To install an image as header resident, specify the /HEADER_RESIDENT qualifier when you install the image. This makes the header of the image file remain permanently resident, saving disk I/O. Specifying the /HEADER_RESIDENT qualifier implicitly makes the images permanently open.
Image headers are stored in paged dynamic memory. The size of the image headers varies.
Frequently accessed images, critical to a site's operations, can be installed as open images. To install an image as permanently open, specify the /OPEN qualifier when you install the image. The image file remains open, so access to the image does not require a call to the file system. The cost of keeping an image file permanently open is approximately 512 bytes of nonpaged dynamic memory per file.
On Alpha systems, you can improve the performance of shared images that have been linked with the qualifier /SECTION_BINDING=(CODE,DATA) by installing them as resident. The code/data sections of an installed resident image reside in pages called granularity hint regions (GHRs). The Alpha hardware can consider a set of pages as a single GHR, mapped by a single page table entry (PTE) in the translation buffer (TB). The result is a reduction in TB miss rates.
Resident image sections remain permanently in physical memory.
You can use ANALYZE/IMAGE on an Alpha system to determine whether an image is linked with /SECTION_BINDING=(CODE,DATA). In the ANALYZE/IMAGE output, look for the EIHD$V_BIND_CODE or the EIHD$V_BIND_DATA symbol; a value of 1 indicates that the /SECTION_BINDING=CODE or the /SECTION_BINDING=DATA qualifier was used, respectively. For more information, see the OpenVMS Linker Utility Manual.
To install shareable and executable images as resident, specify the /RESIDENT=(CODE,DATA) qualifier with the INSTALL commands CREATE and REPLACE.
Resident images can also be installed with shareable linkage sections. The user has no direct control over which images are installed with shareable linkage sections. Images that are eligible for sharing linkage sections are:
Linkage data for these images will be shared if space is provided for images in the process control region. Allocation of this space is governed by the IMGREG_PAGES system parameter. By default, adequate space is provided for the five images. Shared linkage reduces image activation time and decreases demand for physical memory.
You cannot remove images installed with shareable linkage nor can you replace them, except by rebooting the system. To disable shareable linkage sections, set the system parameter IMGREG_PAGES to 0.
Note
Virtual I/O cache can automatically improve image performance at a level similar to that gained by installing images, but also increases memory use. You should decide whether to install it based on the configuration and requirements of your site. For more information on virtual I/O cache, see OpenVMS Performance Management.
You can conserve physical memory by installing images that usually run concurrently from several processes. When an image is not installed, or is installed without the shared attribute, each process running the image requires private sections in memory. Shared images conserve physical memory because only one copy of the code needs to be in memory at any time, and many users can access the code concurrently. Use the /SHARED qualifier to install images as shared images.
When you install an image with the shared attribute, permanent system global sections are created. Execution of non-copy-on-reference global sections requires only one copy per section to be in physical memory, no matter how many processes are running the image to which the sections belong.
The number of images you can install with the shared attribute is restricted by the GBLPAGES and GBLSECTIONS system parameters. For more information on these system parameters, see the OpenVMS System Management Utilities Reference Manual.
There are two ways to allow an image to execute in an enhanced privilege environment:
Caution
Installing an image with enhanced privilege can compromise system security. Make sure the image does not enable a user to regain control with extra privileges enabled.
A nonprivileged process can perform the privileged functions of an executable image when the image is installed with privileges. Install executable images with enhanced privileges by using the /PRIVILEGED qualifier; amplified privileges are temporarily assigned to any process running the image (executable images only), permitting the process to exceed its user authorization file (UAF) privilege restrictions during execution of the image. In this way, users with normal privileges can run programs that require higher-than-normal privileges.
For an image installed with privileges to activate another image, such as a shareable image, either by having it linked to the privileged image or by using LIB$FIND_IMAGE_SYMBOL, the following conditions hold:
6017P052.HTM OSSG Documentation 22-NOV-1996 14:22:32.95
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.