First you must determine how many similar users can be run concurrently
on a given 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 Virtygl !gcil!iIL1IQ This program 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 CP. 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 volumes 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/Montior Analysis Program is to keep the condensed ACUM files
and not the raw data.
If SEEKs data is needed, a sampling technique is suggested. A simple
implementation 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 will collect 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
collecting data for longer periods of time. LOAD ENVIRONMENTS OF VM/370 Two distinct uses of VM/370 can be readily identified and, consequently
some differences 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. 124 IBM iM/370 Programmer·s Guiae
After determining the minimum acceptable performance, perform
external observations of turnaround time on benchmarks and specify a
point beyond which the aQQ1t10n of more users would be However, when that point is reached, more sophisticated internal
measurement is required to deter.ine the scarcest resource ana how the
bottleneck can be relieved by additional hardware.
Several possible
different bottlenecks.
conditions
They are:
can be identified resulting from • 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 working sets of contending nsers# but the processor is being shared among so many users that
each is receiving inadequate 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 With low levels of multiprogramming, user page wait can
become a significant portion of system wait time. Consequently,
processor utilization falls and throughput deteriorates. • 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 circumstances, real storage may be fully committed
because the correct level of multiprogramming is selected, yet device
contention is forcing high I/O wait times and unacceptable processor
utilization.
Estimates ef typical working set sizes are needed to determine how
well an application 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
development, where the improvement in programmer productivity outweighs
the disadvantages of extra overheads, the above points may not be teo
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 operation.
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 concerned 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. Part 2. Control Program (CP) 125
Previous Page Next Page