HP OpenVMS Systems Documentation
OpenVMS Performance Management
12.3 Enlarge Hardware Capacity
If there seem to be few appropriate or productive ways to shift the demand away from the bottleneck point using available hardware, you may have to acquire additional hardware. Adding capacity can refer to either supplementing the hardware with another similar piece or replacing the item with one that is larger, faster, or both.
Try to avoid a few of the more common mistakes. It is easy to conclude that more disks of the same type will permit better load distribution, when the truth is that providing another controller for the disks you already have might bring much better results. Likewise, rather than acquiring more disks of the same type, the real solution might be to replace one or more of the existing disks with a disk that has a faster transfer rate. Another mistake to avoid is acquiring disks that immediately overburden the controller or bus you place them on.
To make the correct choice, you must know whether your problem is due
to either limitations in space and placement or to speed limitations.
If you need speed improvement, be sure you know whether it is needed at
the device or the controller. You must invest the effort to understand
the I/O subsystem and the distribution of the I/O work load across it
before you can expect to make the correct choices and configure them
optimally. You should try to understand at all times just how close to
capacity each part of your I/O subsystem is.
The Guide to OpenVMS File Applications is your primary reference for information on tuning
RMS files and applications. RMS reduces the load on the I/O subsystems
through buffering. Both the size of the buffers and the number of
buffers are important in this reduction. In trying to determine
reasonable values for buffer sizes and buffer counts, you should look
for the optimal balance between minimal RMS I/O (using sufficiently
large buffers) and minimal memory management I/O. Note that, if you
define RMS buffers that are too large, you can more than fill the
process's entire working set with these buffers, ultimately inducing
more process paging.
The considerations for tuning disk file system caches are similar to those for tuning RMS buffers. Again, the issue is minimizing I/O. A disk file system maintains caches of various file system data structures such as file headers and directories. These caches are allocated from paged pool when the volume is mounted for ODS-2 volumes (default). (For an ODS-1 ACP, they are part of the ACP working set.) File system operations that only read data from the volume (as opposed to those that write) can be satisfied without performing a disk read, if the desired data items are in the file system caches. It is important to seek an appropriate balance point that matches the work load.
To evaluate file system caching activity:
When you change the ACP cache parameters, remember to reboot the system
to make the changes effective.
There are two types of solid-state disks:
With solid-state storage, seek time and latency do not affect performance, and throughput is limited only by the bandwidth of the data path rather than the speed of the device. Solid-state disks are capable of providing higher I/O performance than magnetic disks with device throughput of up to 1200 I/O requests per second and peak transfer rates of 2.5M bytes per second or higher.
The operating system can read from and write to a solid-state disk using standard disk I/O operations.
Two types of applications benefit from using solid-state disks:
$ MONITOR /INPUT=SYS$MONITOR:file-spec /VIEWING_TIME=1 PROCESSES /TOPCPU
It can sometimes be difficult to judge whether processes are receiving appropriate amounts of CPU allocation because the allocation depends on their processing requirements.
|The MONITOR collection interval is too large to provide a sufficient level of detail||Enter the command on the running system (live mode) during a representative period using the default three-second collection interval.|
|There is an inequity||Try to obtain more information about the process and the image being run by entering the DCL command SHOW PROCESS/CONTINUOUS.|
Depending on the amount of service required by your system, operating system functions can consume anywhere from almost no CPU cycles to a significant number. Any reductions you can make in services represent additional available CPU cycles. Processes in the COM state can use these, thereby lowering the average size of the compute queue and making the CPU more responsive.
The information in this section helps you identify the system components that are using the CPU. You can then decide whether it is reasonable to reduce the involvement of those components.
The principal body of information about system CPU activity is contained in the MONITOR MODES class. Its statistics represent rates of clock ticks (10-millisecond units) per second; but they can also be viewed as percentages of time spent by the CPU in each of the various processor modes.
Note that interrupt time is really kernel mode time that cannot be charged to a particular process. Therefore, it is sometimes convenient to consider these two together.
|Interrupt 1,2||Interrupts from peripheral devices such as disks, tapes, printers, and terminals. The majority of system scheduling code executes in interrupt state, because for most of the time spent executing that code, there is no current process.|
|MP Synchronization||Time spent by a processor in a multiprocessor system waiting to acquire a spin lock.|
|Kernel 2||Most local system functions, including local lock requests, file system (XQP) requests, memory management, and most system services (including $QIO).|
|Executive||RMS is the major consumer of executive mode time. Some optional products such as ACMS, DBMS, and Rdb also run in executive mode.|
|Supervisor||The command language interpreters DCL and MCR.|
|User||Most user-written code.|
|Idle||Time during which all processes are in scheduling wait states and there are no interrupts to service.|
Although MONITOR provides no breakdown of modes into component parts, you can make inferences about how the time is distributed within a mode by examining some of the other MONITOR classes in your summary report and through your knowledge of the work load.
In OpenVMS Cluster systems, interrupt time per node can be higher than in noncluster systems because of the remote services performed. However, if this time appears excessive, you should investigate the remote services and look for deviations from typical values. Enter the following commands:
Even though OpenVMS Cluster systems can be expected to consume marginally more CPU resources than noncluster systems because of this remote activity, there is no measurable loss in CPU performance when a system becomes a member of an OpenVMS Cluster. OpenVMS Clusters achieve their sense of "clusterness" by making use of SCS, a very low overhead protocol. Furthermore, in a quiescent cluster with default system parameter settings, each system needs to communicate with every other system only once every five seconds.
Multiprocessing (MP) synchronization time is a measure of the contention for spin locks in an MP system. A spin lock is a mechanism that guarantees the synchronization of processors in their manipulation of operating system databases. A certain amount of time in this mode is expected for MP systems. However, MP synchronization time above roughly 8% of total processing time usually indicates a moderate to high level of paging, I/O, or locking activity.
You should evaluate the usage of those resources by examining the IO, DLOCK, PAGE, and DISK statistics. You can also use the System Dump Analyzer (SDA) Spinlock Trace extension to gain insight as to which components of the operating system are contributing to high MP synchronization time. If heavy locking activity is seen on larger multiprocessor systems, using the Dedicated CPU Lock Manager might improve system throughput. See Section 13.2 for more information on this feature.
|CPU tick rate||The percentage of the CPU being consumed by the file system. It is highly dependent on application file handling and can be kept to a minimum by encouraging efficient use of files, by performing periodic backups to minimize disk fragmentation, and so forth.|
The rate of erase operations performed to support the high-water
marking security feature.
If you do not require this feature at your site, be sure to set your volumes to disable it. (See Section 2.2.)
High levels of executive mode time can be an indication of excessive RMS activity. File design decisions and access characteristics can have a direct impact on CPU performance. For example, consider how the design of indexed files may affect the consumption of executive mode time:
Be sure to consult the Guide to OpenVMS File Applications when designing an RMS application.
It contains descriptions of available alternatives along with their
13.1.3 CPU Offloading
$ SET SECURITY file-spec /ACL = (IDENTIFIER=INTERACTIVE+NETWORK,ACCESS=NONE)
Users of standalone workstations on the network can take advantage of local and client/server environments when running applications. Such users can choose to run an application based on DECwindows on their workstations, resources permitting, or on a more powerful host sending the display to the workstation screen. From the point of view of the workstation user, the decision is based on disk space and acceptable response time.
Although the client/server relationship can benefit workstations, it also raises system management questions that can have an impact on performance. On which system will the files be backed up---workstation or host? Must files be copied over the network? Network-based applications can represent a significant additional load on your network depending on interconnect bandwidth, number of processors, and network traffic.