Perf onnance for Time-Shared Multibatch Virtual Machines
Monitoring Recommendations
First you must determine how many similar users can be run concurrently on a giv­
en configuration before the throughput of individual users becomes unacceptable.
Every installation should use the automatic monitoring facilities to simplify and
automate the collection of performance data. A virtual machine should also be set
up to analyze and report the collected data. The VM/370 Performance/Monitor
Analysis Program (VMAP) does such a task. For more information about the
capabilities of this program and for details about ordering it, see the publication Virtual Machine Facility/370 Performance/Monitor Analysis Program. This pro­
gram or user-written analysis programs should be run on a daily basis to analyze
the collected data. Data reduction should preferably be run at off-peak hours to
minimize the effect on the performance of the system that is doing data reduction.
Initially, the data collected with MONITOR default options should be analyzed to
establish a familiarity with the load environment and performance profile of each
virtual machine system and its effect on CPo Once a performance profile is established for each system and associated virtual
machines, the analyst should be able to detect points of contention between
processor(s) storage, I/O, and paging subsystems.
Normally the spool file monitoring options should be used. However, if large vol­
umes of trace data are to be collected, then monitoring to tape should be used.
Tape is also useful if benchmarking is frequently done and all of the new monitor
trace and sampled data must be archived for possible future use. The default mode
of operation of the Performance/Monitor Analysis Program is to keep the con­
densed ACUM files and not the raw data.
If SEEKs data is needed, a sampling technique is suggested. A simple implementa­
tion might be to use a CMS EXEC procedure to enable SEEKs for ten seconds
every ten minutes. This would produce SEEKs data while limiting the volume of
data collected. An alternative is to create a list of devices for which data for the
SEEKs class is to be collected. CP collects data for only those devices in the list.
To create the list, use the INCLUDE or EXCLUDE options of the MONITOR command's SEEK operand. If data is collected for only a few devices, consider col­
lecting data for longer periods of time.
Load Environments of VM/SP
Two distinct uses of VM/SP can be readily identified and, consequently some dif­
ferences in criteria for acceptable performance may occur. The system may be
required to time share multiple batch-type virtual machines with interactive
machines performing minor support roles; or, the system may be primarily required
to provide good interactive time-sharing services in the foreground, with a batch
background absorbing spare resources of real storage and processor.
After determining the minimum acceptable performance, perform external observa­
tions of turnaround time on benchmarks and specify a point beyond which the
addition of more users would be unacceptable. However, when that point is
reached, more sophisticated internal measurement is required to determine the
scarcest resource and how the bottleneck can be relieved by additional hardware.
Several possible conditions can be identified resulting from different bottlenecks.
They are:
Performance Observation and Analysis 59

Real storage levels of multiprogramming are low compared with the number of
contending users. Hence, each user is dispatched so infrequently that running
time or response time may become intolerable.
Storage may be adequate to contain the \vorking sets of contending users, but
the processor is being shared among so many users that each is receiving inad­
equate attention for good throughput. • Real storage space may be adequate for the processor, and a high speed drum
is used for paging; however, some virtual storage pages of some users have
spilled onto slower paging devices because the drum is full. With low levels of
multiprogramming, user page wait can become a significant portion of system
wait time. Consequently, processor utilization falls and throughout deteri­
orates. • Storage, processor, and paging resources are adequate, yet several users are
heavily I/O-bound on the same disk, control unit, or channel. In these circum­
stances, real storage may be fully committed because the correct level of multi­
programming is selected, yet device contention is forcing high I/O wait times
and unacceptable processor utilization.
Estimates of typical working set sizes are needed to determine how well an applica­
tion may run in a multiprogramming environment on a given virtual storage system.
A measure of the application's processor requirements may be required for similar
reasons. Measurements may be required on the type and density of privileged
instructions a certain programming system may execute, because, in the virtual
machine environment, privileged instruction execution may be a major source of
overhead. If the virtual machine environment is used for programming develop­
ment, where the improvement in programmer productivity outweighs the disadvan­
tages of extra overheads, the above points may not be too critical. However, if
throughput and turnaround time are important, then the converse is true, and the
points need close evaluation before allocating resources to a virtual machine opera­
tion.
High levels of multiprogramming and overcommitment of real storage space lead to
high paging rates. High paging rates can indicate a healthy condition; but be con­
cerned about page stealing and get evidence that this rate is maintained at an
acceptable level. A system with a high rate of page stealing is probably thrashing.
Performance -- Mixed Mode Foreground/Background Systems with Emphasis on
Good Interactive Response
Most of the conditions for good performance, established for the time-shared batch
systems, apply equally well to mixed mode systems. However, two major factors
make any determination more difficult to make. First, get evidence to show that, in
all circumstances, priority is given to maintaining good interactive response, and
that nontrivial tasks truly take place in the background. Second, background tasks,
no matter how large, inefficient, or demanding should not be allowed to dominate
the overall use of the time-sharing system. In other words, in mixed mode opera­
tion, get evidence that users with poor characteristics are discriminated against for
the sake of maintaining a healthy system for the remaining users.
A number of other conditions are more obvious and straightforward. You need to
measure response and determine at what point it becomes unacceptable and why. Studies of time-sharing systems have shown that a user's rate of working is closely 60 VM/SP System Programmer's Guide