The Association of System

Performance Professionals

The Computer Measurement Group, commonly called CMG, is a not for profit, worldwide organization of data processing professionals committed to the
measurement and management of computer systems. CMG members are primarily concerned with performance evaluation of existing systems to maximize
performance (eg. response time, throughput, etc.) and with capacity management where planned enhancements to existing systems or the design of new
systems are evaluated to find the necessary resources required to provide adequate performance at a reasonable cost.

This paper was originally published in the Proceedings of the Computer Measurement Group’s 1986 International Conference.

For more information on CMG please visit http://www.cmg.org

Copyright Notice and License

Copyright 1986 by The Computer Measurement Group, Inc. All Rights Reserved. Published by The Computer Measurement Group, Inc. (CMG), a non-profit
Illinois membership corporation. Permission to reprint in whole or in any part may be granted for educational and scientific purposes upon written application to
the Editor, CMG Headquarters, 151 Fries Mill Road, Suite 104, Turnersville , NJ 08012.

BY DOWNLOADING THIS PUBLICATION, YOU ACKNOWLEDGE THAT YOU HAVE READ, UNDERSTOOD AND AGREE TO BE BOUND BY THE
FOLLOWING TERMS AND CONDITIONS:

License: CMG hereby grants you a nonexclusive, nontransferable right to download this publication from the CMG Web site for personal use on a single
computer owned, leased or otherwise controlled by you. In the event that the computer becomes dysfunctional, such that you are unable to access the
publication, you may transfer the publication to another single computer, provided that it is removed from the computer from which it is transferred and its use
on the replacement computer otherwise complies with the terms of this Copyright Notice and License.

Concurrent use on two or more computers or on a network is not allowed.

Copyright: No part of this publication or electronic file may be reproduced or transmitted in any form to anyone else, including transmittal by e-mail, by file
transfer protocol (FTP), or by being made part of a network-accessible system, without the prior written permission of CMG. You may not merge, adapt,
translate, modify, rent, lease, sell, sublicense, assign or otherwise transfer the publication, or remove any proprietary notice or label appearing on the
publication.

Disclaimer; Limitation of Liability: The ideas and concepts set forth in this publication are solely those of the respective authors, and not of CMG, and CMG
does not endorse, approve, guarantee or otherwise certify any such ideas or concepts in any application or usage. CMG assumes no responsibility or liability
in connection with the use or misuse of the publication or electronic file. CMG makes no warranty or representation that the electronic file will be free from
errors, viruses, worms or other elements or codes that manifest contaminating or destructive properties, and it expressly disclaims liability arising from such
errors, elements or codes.

General: CMG reserves the right to terminate this Agreement immediately upon discovery of violation of any of its terms.
 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

WORKLOAD CHARACTERIZATION

Gary M. King
lnternatlollal Business Machines Corporation,'
P.0. Box 390, Poughk••p, i., NY 12602

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
ABSTRACT

A characterization of the resource requirements of a worUoad forms the basis for

the tuning and capacity planning of the computing system which supports the
workload. This paper will discuss the art and science of the workload charac-
terization process by walking through an example characterization of a TSO/Batch
workload running under MVS/XA. The characterization of resource requirements in
terms of processor time. I/O rates, paging and storage will be addressed for the
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

components of the workload.

INTRODUCTION CHARACTERIZED ITEMS

Workload characterization is an important early step in The three major resources of a central computing syste~
managing the performance of a system. A knowledge of the are the processor, storage and I/O. A workload charac-
resource requirements of each component of the workload terization should quantify the use of each of these re-
assists in both the current tuning and the future capac- sources by each component of the workload. Typical items
ity planning of a system. The workload characterization that characterize the use of these resources include:
process includes: defining the major component~> of the CPU time per transaction, working set size, paging and
workload, identifying the items which character'ize re~ daub.,. liD.
source usage, gathering m~asur~ment data and generating
the characterization. The process is not an exact sci- The performance of a workload component 15 determi ned by
ence and sometimes must allow for some llartful ll judge- its ability to obtain the resources it requires. There-
ments. fore, in addition to the quantification of resource de-
mand, the factors that influence the rate at which
Packages which provide "automaticll characterizations by resources can be consumed must also be understood IS part
analyzing SMF/RMF or other data are often llinhel'ited" by of a complete workload characterization. Examples of
new systems programmers and are also available C;Ofl'lller- influencing factors are: CPU queuing delay (function of
cially. An appreciation of the usefulness and accuracy relative dispatching priorities), paging delay (function
of these tools can only be obtained by "getting your feet of paging configuration and total paging rate) and data-
wet'l with some of the same data and techniques used by base I/O time (function of device types and I/O rates).
these tools. This paper intends to tak.e you anUe deep
into the process by presenting an example charac:teriza-
tion of a TSD/Batch workload.
SOURCES OF DATA

WORKLOAD COMPONENTS RMF Monitor I quantifies the total resource consumption

of a workload and, to some degree. break.s down the re-
source usage by wor~lold component. SMF type 30 records.
The first step in the workload characterization process RMF Monitor II and RMF Monitor III report data on indi-
is to define the major components of the workload. The vidual u$ers/jobs. Subsystems which do not report
resource requirements of each component must be identi- transactions through RMF (e.g. IMS) have their own per-
fied in order to understand current tuning sensitivities formance reporters which will be required for transaction
and to assess the impact of differing growth rates of each rates and r'esponse times.
component on capacity planning.
RMF Monitor I produces reports at user specified inter-
Most workloads are not homogeneous. They are generally Yals. These reports can be viewed fn hardcopy form or
composed of different types of work recognizable by their r.cord.d to SMF (typ. 70-78 r.cords). RMF Monitor II 1s
unique performance attributes. Typical factors that can most often run in the foreground to interactively view
be used to isolate the dlfferent components of a workload snapshots of users/jobs from a T50 session. but it can
include: response time requirements, degree of inter- also be run in the background and recorded to SMF (type
action with the system, resource demand, priority (pro- 79 records). RMF Monitor III reports are viewed from a
duction versus test) and workload type (DB/DC, TSO sessfon and may be summarized for any ti_e interval
interactive, graphics, batCh). Examples of workload desired. SMF type 30 records are most useful when written
components are: trivial TSO, non-trivial TSO, production v1a INTERVAL RECORDING to insur. tho data r.fl.cts the
batch, CICS, IMS, and CADAM. appropriate t1me periods used for the characterfzation.
S1nce most of the data descr1bed above can be recorded
to SMF, the opportunity exists for post processing and
comb1ning the data 1nto many useful fo,..s. One such tool
that does this is the Service Level Reporter (SLR)
available from IBM. SlR provides numerous panels and
tables that both characterize and analyze the components
of a ",orkload.
Permission is granted to CMG to publish thh paper.
IBM retains its right to publish this paper e'lsewhere
and distribute copies of it to wha.ever it chooses.

- 789 -

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

Generally, a wor~load characterization should concentrate The characterization of resource consumption of eack
on data obtained during the peak load hour(s) of the prime workload component is summarized in the following chart.
production sh1ft. Tun1ng and planning for the wor~load The data and technique~ used to fill in each row in the
active during this time 15 of most concern; using daily chart will be discussed in detail.
or weekly averages can mask what the system is expected
to deliver during peak load times. To gather the data,

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
RMF should be set to report at 30 or 60 minute intervals,
interval recording for SMF type 30 records should be set CHARACTERIZATION EXAMPLE ...
'to 30 mi nutes,
TRIV ,TRIV BATCH
THE SCIENCE AND ART OF TRANS/SEC IB.90 1. 51 .069
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

CHARACTERIZING A WORKLOAD CPU TIME/TRANI

TCB+SRB .009B .493 7.B3
OTHER .0088 .444 7.04
FOR EXAMPLE,
DBIO/TRANS 120 3362
MCL TSO SYSTEM,
WSS 100 149 174
PROGRAM DEVELOPMENT LSS 95 140
TSD/BATCH
300+ CONCURRENT USERS PGING/TRANS
MVS/XA AUX SWAPS .1 .2 1.6
30B4-0 PAGES/SWAP 65 B8 92
64 MBS OF REAL STORAGE LCL PGIN 1.6 2.4 30
LCL PGOUT 1.6 2.4 30
VIO IN 0 3.0 153
VIO OUT 0 2.B 141
With the prel1m1nar1es out of the way, it 15 t111e to begin
our wa 1k. through an examp 1e work.load characteri zat i on.
If the proper data is recorded to SMF, an SMF post
processor, such as SLR, could be used to derive Indlor
supple~ent the charlcteril.tion. However, the purpose
of this paper is to help the reader beCOMe familiar with TRANSACTIONS PER SECOND
the process of converting the raw dlta from RMF into a
character1zat1on of the workload. In this way, tn,! value
of the existing post J)rocessing tools used by an 'Instal- RMF MONITOR I WORKLOAD ACTIVITY
lation can be understood, and poss1bly, new post proc-
essing tools can be developed. SUM ENDED TRANSACTIONS FROM
EACH COMPONENT'S DOMAINS
Since we will not use a post processing tool in tl,15 ex- AND DIVIDE BY ELAPSED TIME
ample, one valuable source of information will ho't be
ava i 1ab1e to us - SMF type 30 records. When wri t'ten vi a
INTERVAL RECORDING, SMF type 30 records prOVide accurate BATCH = (B2 • 27 + 15) / IBOO
data about individual address spaces that can be combtned = .069 JOBS/SEC
to summarize each component of a workload. The reader
intending on developing a workload characterization tool TRIVIAL TSO = 34205 / 1800
should become familiar with and make use of the data = 18.90 TRANS/SEC
contained in these records.
,TRIV TSO = (IB69 + 811 + 32) / IBOO
We will be characterizing a TSO/batch system runn1ng on = 1.51 TRANS/SEC
a 3084Q with &4 megabytes of real storage. The workload
consists of about 300 TSO users in program development.
The workload will be bro~en down tnto three COMponents:
trivial TSO transactions (fast response time require- Transactions per second can be obtained in a straight-
ments). non-trivial TSO transactions (the remainder of forward manner from the RMF Monitor I WORKLOAD ACTIVITY
the users I interactive work) and batch (the background REPORT. A subset of the columns from such a report is
work submitted by the users). reproduced below. The batch workload component is de-
termined by summing the ended transactions (jobs) of the
The workload components will be identified 1" RMF reports three batch domains and dividing by the reporting inter-
via the SRM domains associated with each. Domains are va' (29 minutes, 59.990 seconds in this case which is
used since they are the smallest common denominator for rounded to 1800 seconds). Similarly, the TSO transaction
each workload component. For exampll, there are multiple rates Ire calculated.
performance groups for T50 but they all are mapped into
tn. ,am. doma'n,. Th. IPS (IEAIPSXX 'n SYSI.PARMLIB)
indtcates trivial TSO is in domain 3, non~trivial TSO is
spread across domains 4, 5, and 6. and batch includes
domains I, 2, and 8. Other domains exist for the system
address spaces (for example, MASTER, JES and VTAM); the
resource consumption accounted for in these doma1ns will
be expl1c1tly ignored but implicitly distributed to the
three workload components.

• 790 •

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

TCB+SRB time for each workload component. However, in

the case of the T50 components it is not so easy.
WORKLOAD ACTIVITY
INTERVAL 29.59.990
TCB+SRB SERVICE UNITS FOR TSD

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
DOMAIN NUMBER ENDED AVG TRANS
NUMBER OF TRANS- TIME
SWAPS ACTIONS HHH.MM.SS.TTT SEPARATING TRIVIAL FROM NON-TRIVIAL
IN RMF MONITOR I WORKLOAD ACTIVITY
001 38 81 000.00.19.5B2 NON-TRIVIAL TRANS. TRANSITION
THROUGH TRIVIAL'S DOMAIN.
001 B6 27 000.07.24.131
ENDED TRANSACTIONS REFLECT
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

003 34300 3420S 000.00.00.290 PROPER DOMAIN

004 1842 1869 000.00.01.715 _ HOWEVER. SERVICE UNITS ACCUMULATED
IN TRIVIAL DOMAIN INCLUDE
DOS 9S7 Sll 000.00.20.004 SERVICE FOR NON-TRIVIALS WHILE
THEY WERE "IN" THE TRIVIAL
006 95 32 000.08.01. 344 DOMAIN.
DOS 35 15 000.06.49.555 _ THUS, SOME SERVICE UNITS MUST BE
SHIFTED FROM THE TRIVIAL DOMAIN
TO THE NON-TRIVIAL DOMAINS.

CPU TIME PER TRANSACTION A.ll TSO transactions lIbegin ll as trivial TSO transactions,
that is, all T50 transactions start in the first period.
Non-trivial transactions are recognized only after con-
CALCULATE TCB+SRB TIME FOR EACH suming more resource than is allowed under the definition
- WORKLOAD COMPONENT. of a trivial transaction. at which time they are switched
to the second period of the TSO performance group. Th,
CALCULATE TOTAL CPU TIME CONSUMED service units acc~ulated by non-trivial transactions
while they were considered trivial is accounted for in
CALCULATE "OTHER" CPU TIME the first period thereby inflating what is reported in
the trivial service statistics. For an accurate de-
DISTRIBUTE "OTHER" TIME IIMONG piction of lSO, so~e of the serviCe must be shifted from
- TNE WORKLOAD CQMPONENTS trivial to non-trivial transactions.
- NOT BAD ==> BY TCB+SRB TIME RATIO
- BEST ==> BY I/O ACTIVITY RATIO

SEPARATING TRIVIAL FROM NON-TRIVIAL

IN RMF MONITOR I WORKLOAD ACTIVITY
The CPU resource requirement for each workload co_panent
w111 be calculated as the approximate CPU time to process
an average transaction. The Il up front ll cost of a t.rans- _ BASEO ON IPS. NON-TRIVIAL SPENDS
action 1~ the TCB and SRB time charged to the translction. 400+ S.U. 'S IN TRIVIAL DOMAIN
The "hidden" cost of a transaction 1s the "uncaptured" (DUR=40o)
time (i.e., processor t1me not charged as TeB or SRB tiMe
to any address space) and the TeB and SRB time of system _ ON AVERAGE, SRM WILL BE ABOUT
address spaces (e.g., JES and VTAM) spent on its behalf. BO S.U.'S LATE IN DETECTING
A "PERIOD SWITCH"_
THUS. ABOUT 480 S.U.'S FOR EACH
CALCULATE TCB+SRB TIME FOR EACH - NON-TRIVIAL TRANSACTION MUST BE
WORKLOAD COMPONENT REMOVED FROM THE TRIVIAL DOMAIN
AND ADDED TO THE NON-TRIVIALS.
DISTRIBUTE AMONG THE TYPES OF
RMF MONITOR I WORKLOAD ACTIVITY - SERVICE BY NON-TRIVIAL RATIOS.

CALCULATE CPU AND SRB SERVICE

UNITS FOR EACH WORKLOAD COMPONENT From the IPS of our example system, it 1s observed that
the duration for the trivi.l TSO period is 400 service
units (DUR=400 for flrst period TSO). This indlcates
CONVERT SERVICE UNITS TO TIME that transactions th.t consume more tnan 400 service
unlts will be switched to second period, thus becomlng
non-trivial transactions. The switch does not occur
precisely When a transaction consumes its 400th service
THe RMF Monitor I WORKLOAD ACTIVITY REPORT prov1du I unft. Period switching is accomplished by a routine
Masure of the TeB t11le (CPU service units) and SRI~ time which looks periodically to see which transactions have
(SRB service units) conscJmed by the work running 1n each exceeded their duration. Thus, on average, transactions
domain. Thus, it would seem tllat a stra1ghtfoNIrd con- will consume a little more service in a period than al-
version of service units to time would provide the lowed for by the duration. On a 3084Q the period ~witch

• 791 •

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

occurs about 1/6 seconds late. meaning a transaction

could consume about 1/6 its absorption rate (given in the
WORKLOAD ACTIVITY REPORT but not reproduced here) before SEPARATING TRIVIAL FROM HON-TRIVIAL
being switched. On our example system. TSO lI absorbs" 1N RMF MONITOR I WORKLOAD ACTIVITY
about 480 service units per second indicating that period
switching would occur about 80 service units late.

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
Therefore. each non-trivial transaction has about SUM OF NOH-TRIVIAL DOMAINS' SERVICE
400+80=480 service units which must be removed from
trivial's statistics and added to its own statistics. ~ OF TOTAL
The 480 service units per non-trivial transaction that ICC = 1940665 19.9
must be shifted is composed of four different components CPU = 412B773 42.4
of service: 10C, CPU, MSO and SRB. It 1s assumed that MSD = 3347236 34.3
non-trivial transactions consume the different types of SRB = 330409 3.4
service in the same proportion throughout the life of the
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

transaction. Therefore, the proportion of servic:e that TOT = 97470B3 100.0

.I~es up the 480 service units will be taken from the
proportion of service reported in the non-trivial service
statistics. SERVICE TO REMOVE FROM TRIVIAL
(AND ADD TO NON-TRIVIAL)
Trivial TSO·s service is reported in domain 3. Non-
trivial TSO·s service is reported in domains 4. 5, and TOT = 480 • 2712 = 1301760
6. BatCh's service is reported in domains 1. 2, and 8.
A condensed WORKLOAO ACTIVITY REPORT is reproduced below. IDC = 1301760 • . 199 = 259050
The service actually reported for individual domains has CPU = 1301760 • .424 = 551946
been summed as appropriate in interest of saving space. MSO = 1301760 • . 343 = 446504
SRB = 1301760 • .034 = 44260

WORKLOAD ACTIVITY ESTIMATED TRIVIAL SERVICE

SERVICE DEFN COEFF SU/SEC= 346.1 Ioe = 466512 - 259050 = 207462
IOC=6.0 CPU=11.0 MSD=3.0 SRB=IO.O CPU = 1572263 - 551946 = 1020317
MSO = 1002253 - 446504 = 555749
DOMAIN INTERVAL SERVICE ENDED SRB = 27B951 - 44260 = 234691
NUMBER (TOTAL, BY TYPE TRANS-
AND PER SECOND) ACTIONS
ESTIMATED NOH-TRIVIAL SERVICE
003 ICC= 466,512 34205
CPU= 1,572,263 IDC = 1940665 • 259050 = 214BI27
MSD= 1,002,253 CPU = 412B773 • 551946 = 46B0719
SRB= 278,951 MSO = 3347236 • 446504 = 3793740
TOT= 3,319,979 SRB = 330409. 44260 = 374669
004 10C= 1,940,665 2712
• CPU= 4, 12B, 773
The proportion of the types of service for non-trivial
005 MSD= 3,347,236
• SRB= 330,409 transactions is given above. Since there Ire 2712 non-
006 TOT= 9,747,DB3 trivial transactions, 2712-480=1301760 service units Must
be shifted from the trivial to the non-triVial statis-
001 10C= 2,751,125 124 tics. The shift is done using the non-triVial TSO pro-
•
002
CPU=
MSD=
3,450,590
3,269,776
portion and is shown above. Note that a significant
percentage of the service reported for trivial TSO hIS
• SRB= 225,073 been removed from its statistics. Th1s COMMents on the
OOB TDT= 9,696,564 sizeable inaccuracy in trivial TSO resource consumption
that was avoided by recognizing the impact of non-trivial
TSO transactions on the reported statistics.

. 792 .

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

measurement interval, Thfs t1l11e may be calculated from

the CPU ACTIVITY REPORT reproduced below.
CALCULATE TCB+SRB TIME FOR EACH
WORKLOAD COMPONENT The average CPU utilization during the ,nterval 1s cal-
culated as 100% minus the average wait time 'percentage.
In our example, the average utilization was 69.77%. This

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
TIME = S.U. / COEFF / SRM 3084 SU/SEC can be 1nterpreted as; on average each CPU in the system
was busy 69.77 hundredths out of each second. The total
CPU COEFF = 11.0 CPU time consumed during the interval is equal to the
SRB COEFF = 10.0 number of CPUs times the average utilization times the
SU/SEC = 346.1 number of seconds in the interval. Our example shows the
total CPU time consumed to be 5024.4 seconds during the
measurement inte~val.
TRIVIAL TSO TCB+SR8 TIME
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

= (1020317/11+234691/10)/346.1
= 335.8 SECONDS CPU ACTIVITY
NON-TRIVIAL TSO TCB+SRB TIME
= (4680719/11+374669/10)/346.1 INTERVAL 29.59.990
= 1337.7 SECONDS CPU WAIT TIME
BATCH TCB+SRB TIME NUMBER PERCENTAGE
(3450590/11+225073/10)/346.1
= 971. 4 SECONDS 0 21.84
26.23
Once the service ur.its are distributed properly among the 2 32.82
wor~load components, the reB and SRB times can be calcu·
lated by converting the appropriate service unft:s into 3 40.04
time. A service unit to time conversion factor I!xists
for each CPU type. Recent versions of RMF provide the TOTAUAVERAGE 30.23
factor in the upper right hand corner of the WORKLOAD
ACTIVITY REPORT (see earlier example report). Otherwise,
the IIInitialization and Tuning Guide u provides a table
of the conversion factors.
TeB time can be found by tak.ing the CPU service units, CALCULATE IIOTHER" CPU TIME
dividing by the CPU service definition coefficient Ind
dividing the result by the appropriate CPU service units
per second conversion factor. SRB t1me ;s found 1n the ·OTHER" ACCOUNTS FOR
salle manner using SRB service units. The service- defi-
nition coefficients are given at the top of the WORKLOAD • UNCAPTURED TIME
ACTIVITY REPORT (see earlier example report). Fc)!" our . TCB+SRB OF SYSTEM ADDR SPC
example, the TCB+SRB time was found to be 335.8 ~.econds
for trivial lSD, 1337.7 seconds for non-trivial TSO and OTHER = TOTAL CPU TIME MINUS
971.4 seconds for batch. These times represent the sum WORKLOAD COMPONENT TCB+SRB TIME.
of the time spent for all transactions of each type during
the measurement interval.
OTHER CPU TIME
=TOTAL - TRIV - NONTRIV - BATCH
TOTAL CPU TIME CONSUMED = 5024.4 - 335.8 - 1337.7 - 971.4
= 2379.5 SECONDS
RMF MONITOR I CPU ACTIVITY
AVERAGE CPU UTILIZATION EQUALS The difference between the total CPU time consumed and
100 - AVG WAIT TIME PERCENTAGE. the TCB+SRB time attributable to the workload components
during the measurement interval 15 the hidden or "other"
TOTAL CPU TIME CONSUMED EQUALS CPU time. This time represents two major categories of
- AVERAGE CPU UTILIZATION TIMES CPU consumption. The largest category i~ "uncaptured"
RMF INTERVAL TIME IN SECONOS ti.e - time not charged to any address spacels TeB or SRB
TIMES NUMBER OF CPUS. statistics. The uncaptured time includes CPU consumed
by various system services th.t cannot •• sily b. charged
to the requesting address space, for example, I/O inter-
AVO CPU BUSY = 100 - 30.23 rupt handling. Th@ second category of Il othl8r" CPU time
= 69.7~ 1s the TCB+SRB time accounted to system address spices
such as JES and VTAM. These address spaces are performing
TOT CPU TIME = .6977 • 1800 • 4 services 1n behalf of the major wor~load components. In
= 5024.4 SECONDS the example. the total Il other lt time 1's 2379.5 seconds.

The TeB and SRB time of the workload components account

for only a part of the total CPU resource consumed by the
workload. The total CPU time that must be accounted for
is the total CPU time consumed during the RMF Morl1tor I

- 793 .

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

any component·s TCB-+-SRB time. This is often mist~kenly

ignored in CPU queuing analysis. CPU queuing as an "in-
DISTRIBUTE "OTHER" CPU TIME fluencing factor l • is discussed later in this paper.
AMONG THE WORKLOAO COMPONENTS

BEST ==> BY 1/0 ACTIVITY RATIO DATABASE I/O PER TRANSACTION

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
NOT BAD ==> BY TCB+SRB TIME RATIO
RMF MONITOR I WORKLOAD ACTIVITY
RMF MONITOR I DEVICE ACTIVITY
TCB+SRB % OF TOTAL RMF MON I PAGING/SWAPPING OS ACT.
TRIVIAL 335.8 12.7 SUM NON-PAGING DEVICE ACTIVITY
NON-TRIVIAL 1337.7 50.6 RATES ==> TOTAL DATABASE I/O
BATCH 971. 4 36.7 PER SECOND FOR SYSTEM
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

TOTAL 2664.9 100.0 01 STRIBUTE BY 10C S. U.• S

OTHER % OF TOTAL
The I/O activity to the database volumes of the system
TOTAL 2379.5 100.0 must be distributed among the workload components. This
1s accomplished by first determining the total non-paging
TRIVIAL 3D2.2 12.7 I/O rate of the system and then distributing it vi. the
NON-TRIVIAL 1204.0 50.6 proportion of IOC service units among the workload co.-
BATCH 873.3 36.7 ponent$.

The "other" CPU time must be distributed among the work- TOTAL DATABASE 1/0 PER SECOND
load components. My own studies have shown that the most
,ccul"'ate distribution of this Hother" time is madE~ by the
ratio of 110 activity among the workload components. For SUM TOTAL I/O'S AND SUBTRACT
example, if trivial TSO accounts for 20% of the I/O's in PAG1NG liD'S
the system, it would be charged with 20% of the "otner ll
time. The I/O's for a workload component would include
both paging and Gatabase (i .e. non·paging) I/O. For
I SUM ACTIYITY RATE
this example, it is pr@matul"'e to distribute basecl on I/O ACROSS ALL LCU'S 495 / SEC
since that part of the characterization has not yet been
addressed. Therefore. as a reasonable a1ter"4th'e. the SUM ACTIVITY RATE FOR
1I 0ther
ll
CPU time i ~ di st ri buted in the same proportion ALL PAGING DEVICES = 64 / SEC
as TCB-+-SRB time. An ambit10us reader can try a clistr1b-
uti on based on I/O at the conclusion of the example
characterization.
TOTAL DATABASE I/O PER SECOND
= 495 - 64 = 431 / SEC
CONVERT COMPONENT CPU TIME
TO CPU TIME PER TRANSACTION
The I/O activity of the system is found in the RMF Monitor
DIVIDE COMPONENT TIME BY NUMBER I DIRECT ACCESS DEVICE ACTIYITY report; a subset of an
O' TRANSACTIONS IN INTERVAL. example report is rearoduced below. The DEVICE ACTIVITY
RATE column lists the 1/01s per second to each volume;
the rate for all the volumes on a LCU is summarized in
TRIVIAL TSO TCB'SRB CPU TIME/TRANS the LeU row following e.ch group of volumes. For example,
335.8 I 34205 devices 260-267 mak.e up LeU 018 and their total activity
= .0098 SECS I TRANS was 17.788 I/O·s per second.
TRIVIAL TSO "OTHER" CPU TIME/TRANS Summing all the LCUs· activity rates for the example
= 302.2 / 34205 system indicated a rate of 495 1/0·s per second. However,
= .0088 SECS / TRANS some of the volumes across some of the LeU's were used
as paging devices. Since paging will be trelted sepa·
rately in the characterization, the activity for these
ETC. FOR OTHER WORKLOAD COMPONENTS paging volumes must be removed from the total for the
system. Summing just the activity rate on the paging
volumes yielded 64 paging 1/0 1 s per second. Thus, the
total database activity for the system was 49S-64=431
The CPU time per transaction for each workload cClmponent I/Ols per second.
can now be calculated by simply dividing the toU,l time
for the component by the number of transactions cClmpleted
during the measurement Hlterval. TCS-+-SRS and "other" CPU
time are k.ept separate for use in analyzing the CPU
queui ng de lay component of response t 1me. CPU qlleu1 ng
time is a function of the relative dispatching priorities
of the workloads. I n genera 1, the lIother" t 1me a,cross
all workload components runs at a higher priorit)' than

- 794 -

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

DIRECT ACCESS DEVICE ACTIVITY WORKING SET SIZE

(AVERAGE REAL STORAGE FRAMES)
DEViCE AVG
DEV VOLUME LCU ACTIVITY RESP RMF MONITOR I WORKLOAD ACTIVITY

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
NUM SERIAL RATE TIME
USING MSD AND CPU, CALCULATE
260 C45IOI 018 0.333 12 AVERAGE REAL STORAGE FRAMES
261 TSOO06 018 10.173 25 PER TRANSACTION

267 LARG05 018 0.000 0 AVG REAL STG FRAMES PER TRANSACTION
LCU 018 17.788 22 = 50
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

• (MSO / COEFF) / (CPU 1 COEFF)

TRIVIAL TSD WSS

• 50 • (555749/3) 1 (1020317/11)
LCU 01C 0.127 25 = 100 FRAMES
NON-TRV TSO WSS = 149 FRAMES
BATCH WSS = 174 FRAMES
LCU 02C 6,067 36

The average real storage frames used by an address space

is often referred to as its Il wor king set size,1I This may
be estimated for each workload component using the MSO
DISTRIBUTE TOTAL I/O'S AMONG and CPU service units. MSO service units are calculated
THE WORKLOAD COMPONENTS as a CPU time-weighted average of real storage usage.
Solving the MSO formula for real storage frames yields
the formula given above. Extracting M50 and CPU serv1ce
BY RATIO OF IOC SERVICE UNITS units and the service definition coefficients from ear-
lier charts allows the working set size of tne average
address space of each workload component to be derived,
TOTAL DBIO/SEC = 431 On,. again use is made of the work to distribute service
between the trivial and non-trivial TSO components. It
should be noted that sinee M50 is a CPU time-weighted
TRIV ,TRIV BATCH value, the MSO sum for a DOMAIN is also CPU time-weighted.
Therefore, the average real storage frames per address
IOC 207462 2148127 2751125 spaee will be skewed toward those address spaces in the
domain which consume the most CPU time. This only becomes
I OF TOTAL 4,1 42,0 53,9 a problem if there is a wide variation 1n the CPU time
consumed by each address space within a domain.
OBIO/SEC 18 181 232
TRANS/SEC 18,9 I. 51 ,069
LOGICAL SWAP SIZE
OBIOITRANS 120 3362 (AVERAGE REAL STORAGE FRAMES)

RMF MONITOR II ASO REPORT

IOC service units are a measure of the I/O at:t1v1ty ac-
counted to a workload component. Therefore. the total
I/O rate of tne system will be distributed using the RECOGNIZE LOGICALLY SWAPPED
proportion of IDe service units among the workloa,:j com'" ADDRESS SPACES BY CL = LO
ponents. The already c~pleted work to distribute ser-
vice between trivial and non-trivial TSO pays I bonus
dividend here since it also accounted for IDe service AVERAGE RSF FOR THESE
units. Extracting the IOC service for each work.load - AOORESS SPACES FOR EACH
component from an earlier chart allows the proportion to WORKLOAD COMPONENT
be calculated. The proportion is applied to the system's
total I/O activity to calculate the I/O's per second for
each workload component. Dividing by the transactions
per second yields the database rlOls per transact'on. The working set of each workload component is not the only
consumer of the real stor,ge resource. To improve re-
sponse time and/or reduce the size of the paging config-
uration, an idle user's pages may be kept in storage
rather than swapping them out to page or swap datasets.
Those idle users kept in real storage are referred to as
being Ill og ical1)' swapped. II
The number of logically swapped users in a system can be
found tn tn. RMF Mointor I CPU ACTIVITY REPORT (tni, part
of the report is not reproduced here). This number 1s a

. 795 .

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

function of the contention for real storage and the ac-

tivity of the users.
SWAPS PER TRANSACTION
The size of each logically swapped user can be estimated
using the RMF Monitor II ASD report, an example report
is given below. The workload component can be identified RMF MONITDR I WORKLOAD ACTIVITY

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
by its domain. Logically swapped users are recognized
by an IILO" in the CL column. By averaging the RSF (Real DIVIDE NUMBER OF SWAPS BY
Storage Frames) for all logically swapped users for each ENDED TRANSACTIONS
workload component, the average logical swap size can be
found.

TRIVIAL TSO SWAPSITRANS

= 34300 / 34205
RMF MONITOR II ASD A,A,A = 1.0
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

C RS WS NON-TRIVIAL TSO SWAPS/TRANS

JOBNAME OMN L F IN = (IB42+957+95) / (1869+B11+32)
= 1.1
096SLPIG I OT 0 105
LAURIE 3 LD 66 62 BATCH SWAPS/TRANS
STEVE 4 WT 0 64 = (86+95+35) / (B2+27+15)
096KRP 4 LO 92 56 = 1.7
WAYNE 3 WT 0 77

The swaps per transaction can be calculated from the RMF

Monitor I WORKLOAD ACTIVITY REPORT. Referring to an
earlier example report, the column labelled "NUMBER OF
SWAPS" oan be divided by the ENDED TRANSACTIONS to
Paging to auxiliary storage can have a large effect on produce the swaps per transaction.
the performance of a transaction. Three major categories
of paging will be characterized: swapping, local (non-
s•• p) and VIC.
AUX SWAP PERCENTAGE

AUX SWAPS PER TRANSACTION RMF MONITOR I SWAP PLACEMENT

RMF MONITOR I WORKLOAD ACTIVITY CALCULATE THE PERCENTAGE OF SWAPS

RMF MONITOR I SWAP PLACEMENT THAT ARE DONE TO AUXILIARY STORAGE
(PAGING ACTIVITy PAGE 2)
CALCULATE NUMBER OF SWAPS
PER TRANSACTION AUX % FOR TERMINAL WAIT SWAPS
CALCULATE PERCENTAGE OF SWAPS = 9.2%
- THAT GO TO AUXILIARY STORAGE
MULTIPLY ABOVE FOR EACH AUX % FOR NON-TERMINAL WAIT SWAPS
WORKLOAD COMPONENT
= (TOT AUX - TW AUX) / (TOT - TW)
= (3842 - 3382) / (37410 - 36917)
= 93.3%
Swapping to auxiliary storage generally involves the
transfer of SO to 100 pages from real storage to several
paging devices. Swapping occurs for many reasons such
as planned idleness (T50 terminal wait), unplanned idle- The RMF MONITOR I SWAP PLACEMENT REPDRl (e,ample report
ness (detected wait) and resource balancing (exchange). given below) can be used to calculate the percentage of
Not all swaps are to auxiliary storage. Address spaces each swap type that takes place to auxiliary storage.
may be in the swapped-out state but their pages remain For terminal wait swaps, the percentage to auxiliary
in real storage - as mentioned earlier, this is called a storage is listed in the report. For non-terminal wait
logical swap. To calculate the number of swaps to aux- swaps, an average percentage to auxiliary can be found
iliary storage per transaction, the total numbel" of swaps as shown above.
and the percentage that are to auxiliary storage must be
determi ned.

- 796 -

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

S WA P PLACEMENT ACTIVITY PAGES PER AUX SWAP

AUX
STOR QUICK WAY

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
TOTAL TOTAL
- TAKEN DIRECTLY FROM RMF
TERMINAL CT 36917 3382 MONITOR I SWAP PLACEMENI
INPUT/OUTPUT RT 20.51 1.88 AVG PAGES PER SWAP IN
WAIT % 98.7% 9.2%
- ASSUMED TO BE THE SAME FOR
LONG CT 55 46 ALL COMPONENTS
WAIT RT 0.03 0.03
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

% 0.1% 83.6%
LONGER WAY
OETECTEO CT 302 278
WAIT RT 0.17 0.15 - USE RMF MONITOR II TO DERIVE
% 0.8% 92.1% AVERAGE FOR EACH WORKLOAD
COMPONENT
- ASD REPORT: DMN, RSF=O, WSIN
TOTAL CT 37410 3842
RT 20.78 2.13
% 100.0% 10.3% Given that a swap did occur to auxl1tary storage, how many
pages were included in the swap group? The easiest way
to approximate th1s is to use the AVG PAGES PER SWAP IN
number from the SWAP PLACEMENT report and assume it ap-
plies equally among all workload components. A better.
but longer, method makes ~se of the RMF Monitor II ASD
AUX SWAPS PER TRANSACTION report. An example report appeared earlier in this pi-
per. The WSIN column gives the size of the swap group.
Any address space that has 0 RSF" (Real Storage Frames)
APPLY AUX SWAP ~ TO WKLD COMPONENTS has been swapped to auxiliary, thus its WSIN reflects its
current swap group size. By averaging the WSIN of all
- TRIVIAL AND NON-TRIVIAL TSD address spaces in each workload component (identified by
HAVE ONE TERMINAL WAIT SWAP domain) that have R$F" of 0, an accurate value for pages
AND REST ARE NON-TERMINAL WAIT per auxiliary swap can be derived.

- SATCH HAS ONLY NON-TERMINAL

WAIT SWAPS
LOCAL AND VIO PAGINGITRANSACTION
"". PROBLEM """
TRIVIAL TSO AUX SWAPSITRANS
: 1.0" .092 : .1 DISTRIBUTING LOCAL AND VIO PAGING
AMONG THE WORKLOAD COMPONENTS???
NON-TRIVIAL TSO AUX SWAP/TRANS
: 1.0".092 + .1".933 :.2 RMF MONITOR III CAN BE USED TO
DISTRIBUTE THIS PAGING BETWEEN
BATCH AUX SWAPSITRANS TSO AND BATCH USING "DELAYS".
: 1.7".933 = 1.6
HOWEVER, IT CAN ONLY APPROXIMATE
- THE SPLIT BETWEEN TRIVIAL
AND NON-TRIVIAL TSO.
To calculate the auxiliary storage swaps per transactton.
the auxiliary swap percentage must be applied to the type TNEREFORE, WE HAVE TO APPLY
of swaps done by each workload component. T50 trans- - "ENGLISH" TO THIS SEPARATION.
actions always have One and only one te~in.l watt swap;
anything above one swap per trans&ct1on Must be of the
non-terminal wa1t variety. Batch swaps w111 never be
te~t".l waits. With these assumptions, the auxiliary CharacteriZing local (non~swap) and VIa paging per
swap percentage May be applied IS shown above. tr.nslct1on presents some challenges (SMF type 30 records
would be especially useful here). RMF Monitor I provides
system totals for local (non-swap) and VIC paging rates.
Unfortunately. it gives no hint on how to distribute this
paging aMOng the workload components (there .re no ser-
vice units for paging!). RMF Monitor III cln be used to
distribute paging delays between T50 and b.tch. Howev,r,
it cln only approximate the split between trivial Ind
non-trivial TSO. Thus, assumptions .bout the behavior
of the worKload components must be f.ctored into In
analysis of the data.

- 797 •

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

LOCAL PAGE-INS PER TRANSACTION RMF MONITOR III

BREF TIME=XX,RANGE=1800
RMF MONITOR I PAGING ACTIVITY
RMF MONITOR III STOR DELAY STOR TSO,ALL

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
DISTRIBUTE LOCAL PAGE-INS/SEC
BETWEEN TSO AND BATCH VIA -- % DELAYED FOR --
PERCENTAGES IN RMF MON III JOBNAME OMN LOCL VIO
LAURIE 3 5 o
TOTAL LOCAL PAGE-INS/SEC = 35.12 WAYNE 3 5 o
STEVE 4 4 I
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

STOR,LOCL DELAY % OF TOTAL

TSO 64 94
BATCH 4 6
TOTAL 6B 100

TSO PAGE-INS/SEC = .94"35 12 = 33.05 SPLITTING TSO PAGE-INS/SEC

BETWEEN TRIVIAL AND NON-TRIVIAL
BATCH PG-INS/SEC = .06"35 12 = 2.07
ARTFUL JOB TO BREAKDOWN TSO
LOCAL PAGE-INS BETWEEN TRIVIAL
The total local page-ins. that must be accountecl for is AND NON-TRIVIAL.
9i.en 1n the RMF Monitor I PAGING ACTIVITY REPORT, •
subset of th1 s report for our examp 1e system 1!, 91 Vltn _ NON-TRIVIAL TSO IS QUITE BATCH-
below. The non-swap, non-VIO page-in rate of 35.12 re- LIKE. WE WILL ASSUME IT PAGES
presents the local page-in rate of the system. AT THE SAME RATE AS BATCH ON A
PER TRANSACTION ELAPSED TIME
BASIS.
P A GIN G ACT I V I T Y
BATCH PAGE-INS/TRANS
PAGE IN = PAGE-INS/SEC / TRANS/SEC
= 2.07 / .069
NON = 3D
CATEGORY SWAP SWAP
AOOR SPC FROM RMF WORKLOAD ACTIVITY
VIO 15.09 (AVERAGE TRANSACTION TIME),
NON VIO 126.06 35.12 BATCH E.T. = 159 SECONDS
NON-TRIVIAL E.T .• 12.B SECONDS
SUM 126.06 50.21
NON-TRIVIAL TSO PAGE-INS/TRANS
= (BAT PIN/BAT ET) • NT ET
= ( 30 / 159 ). 12.B
= 2.4
From RMF Monitor III. the percentage of time a workload TRIVIAL TSO PAGE-INS
component ;s delayed due to local paging can bl! found. = TSO PGINS - NON-TRIV PGINS
The proportion of total paging delay of each wClrk,load = 33.05 1.51*2.4
component ;s used to distribute the local page··;n rate = 29.4
of the system. Using the BREF option, the reporting pe-
riod of RMF Monitor III can be matched to the RMF Monitor TRIVIAL TSO PAGE-INS/TRANS
I interval. A sample of RMF Monitor III output from tnt = 29.4/IB.9
sTaR report is given below. Summing the LOCL delay for = 1.6
all TSO users yields a total of 64 while the sum for batch
jobs is 4. Therefore, TSO is assigned 64/68 0" 94~ of
the local page-in rate of the system. Batch i!. assigned
6% of the tota 1. 150 has been estimated to account for 33.05 local page-
ins per second. There is no precise way of splitting this
rate between trivial Ind non-trivial transactions.
The assumption is made that non-trivial T50 1s somewhat
similar to batch and will page-in at a rate consistent
with batch. The page-ins per batch job can be calculated
as the page·ins per second assigned to batch divided by
the batch jobs per second. In the example, batch is
paging at 2.07 page-ins per second and the batch job rate
is .069 jobs per second; this indicates the average batch

. 798 .

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

job aoes 30 page-ins. From the RMF Monitor I WORKLOAD field .long with all the swap page-outs. These local
ACTIVITY REPORT, the w~1ghted-average elapsed time across page-outs can be isolated by subtracting the swap page-in
all batch domains is 159 seconds while thlll weighted- rate (126.06 from the example report given earlier) from
Iverlge non-trivial TSO transaction lasts about 12.8 the swap page-out rate (128.13 from the report below).
seconds. If a batch job does 30 page-ins in 159 seconds, The total local page-out rate of the system is
th.n we will assume the average non-trivial TSO trans· 33.10+2.07=35.17 pages per second. The page-outs per

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
.ction will do (12.8/159)*30 or 2.4 page-ins in 12.8 transaction can be found by calculating the ratio of
seconds. pago-outs to pago-ins (35.17/35.12=1.001) and multIplying
the page-ins per transaction by this ratio. The ratio
Onci the page-ins per non-trivial transaction has been will usually be very close to 1 since to page-in a page,
• sti~ated. the page-ins per trivial transaction can be it must have been written out sometime 1n the past .
c.lculated. Non-trivial TSO completes l.51 tranut:tions
per second. If each one does 2.4 p.ge-ins, than non-
trivi.l 1S0 accounts for 1.51*2.4=3.63 page-ins I)er sec-
ond. Since TSO was assigned 33.05 page-ins per second, P A GIN G ACT I V I T Y
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

trivial must have accounted for 33.05-3.63 or 29.4 page-

ins per second. Dividing this rate by the trivial TSO PAGE OUT
trlnsaction rate of 18.9 yields an average of 1.6 page-
ins per trivial TSO transaction. NON
CATEGORY SWAP SWAP
AODR SPC
LOCAL PAGE-OUTS PER TRANSACTION VIO 13.91
NON VIO 128.13 33.10
RMF MONITOR I PAGING ACTIVITY
SUM 128.13 47.01
CALCULATE RATIO OF PAGE-OUTS
TO PAGE-INS.
APPLY RATiO TO EACH WORKLOAD
COMPONENT.

WHERE ARE LOCAL PAGE-OUTS COUNTED?

- FROM PAGE REPLACEMENT
=> NON-SWAP PAGE OUTS VIO PAGE-INS PER TRANSACTION
- FROM LOGICAL SWAP TRIM
=> NON-SWAP PAGE OUTS
- FROM PHYSICAL SWAP TRIM RMF MONITOR I PAGING ACTIVITY
=> SWAP PAGE OUTS RMF MONITOR III STOR DELAY

TOTAL LOCAL PAGE-OUTS OISTR18UTE VIO PAGE-INS/SEC

= NON-SWAP PAGE OUTS BETWEEN TSO ANO BATCH VIA
• (SWAP PAGE-OUTS - SWAP PAGE-INS) PERCENTAGES IN RMF MON III
= 33.10 • 2.07
= 35.17 ASSUME TRIVIAL T50 DOES
NO VIO PAGING.

TOTAL LOCAL PAGE-INS = 35.12

TOTAL VIO PAGE-INS/SEC = 15.09
OUT/IN RATIO = 35.17/35.12 = 1.001
STOR. VIO OELAY 11: OF TOTAL
TSO 3 3D
LOCAL PAGE-OUTSITRANS BATCH 7 70
= PAGE-INSITRANS ' OUT/IN RATIO TOTAL 10 100

TSO VIO-PINS/SEC = .30'15.09 = 4.53

For a page to have been a local page-in, it .ust hive been
a local page-out so-eti.e in the past. Therefore, the BATCH VIO-IN/SEC = .70'15.09 =10.56
local pago-out activity of tho system will be distributod
..ong the workload co.ponents by tht proportion of local
page-in activity. TRIV TSO VIO PINS/TRANS =0
Local page-out activity is accounted for in two dHferent NON-TRIVIAL VIO PAGE-INSITRANS
places in the RMF Monitor I PAGING ACTIVITY REPOR'r, a = 4.53 / 1.51 = 3.0
subset of the report from the example system is rl!-
produced below. Local page-outs generated by both the BATCH VIO PINSITRANS
page replacement (plge stealing) activity in the :~ystell = 10.56 / .069 = 153
and the trimming of working sets during logical swapouts
Ire accounted for f:S non-swap, non-VIC page-outs (33.10
in the example report). Local page-outs that result from
triMming of working sets during swapouts to auxiliary Calculating the VIa page-in activity for the workload
stor.g•• ,.. accumulated in the swap, non-VIO p.ge"out components is analogous to the local page-in analysis.

- 199 -

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

RMF Monitor III provides the VIO delay percentage, which

are used to distribute the VIa page-in rate between TSO
and batch. The VIC rates and delays for the exa"'~lle PAGE-IN DELAY TIME
system are reproduced in several sample reports appearing
earlier in this paper. ]t is assumed that trivial TSO = SUM STOR,LOCL / PAGE-INS/SEC

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
transactions do not cause VIa paging. Therefore, all TSO
VIO paging ;s charged to non-trivial transactions
VID PAGE-IN OELAY TIME
= SUM STOR,VIO I VIO PINSISEC
VIO PAGE-OUTS PER TRANSACTION
SWAP-IN DELAY TIME
RMF MONITOR I PAGING ACTIVITY
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

= SUM STOR,SWAP I TOT AUK SWAPISEC

CALCULATE RATIO OF PAGE-OUTS
TO PAGE-INS.
DATABASE 110 DELAY TIME
APPLY RATIO TO EACH WORKLOAO
COMPONENT. = WEIGHTED AVERAGE OF RESPONSE
TIMES ACROSS ALL DEVICES
TOTAL VIO PAGE-INS = 15.09
TOTAL VIO PAGE-OUTS = 13.91
Delay time, for the different categories of paging are
OUTIIN RATIO = 13.91/15.09 = .92 .11 found in I 51.ilar manner. The delay percentages are
summed across all address spaces in the system using the
appropriate colu.n from RMF Monitor III. The appropriate
VIO PAGE-OUTS/TRANS paging rat. is extracted from RMF Monitor I. Make sure
= PAGE-INS/TRANS • OUTIIN RATIO the reporting intervals of both RMF Monitors are the
la_e. The delay milliseconds are calculated by dividing
the s~d paging delay percentage b.Y the paging rate and
multiplying by 10 (swlp-in delay is usul1ly calculated
VIa page-outs per transaction are calculated 1n the same by dividing by the auxi11ary storage swap rate to provide
way local page-outs were derived, The rat10 of VIa the average tiMe for the entire swap-in, rather than a
page-out rate to VIa page-in rate is calculated and used tt.e per page). For example, the sum of local page-in
as a multiplier on the VIO page-ins per transaction. delay for the example system WIS 68~ the local page-in
rate was 35.12. Therefore, during this measureMent in-
------------- ---- tervIl, local page-in de11y WIS 10*68/35.12=19 millisec-
onds. Similarly, the average ~IO page-1n delay during
INFLUENCING FACTORS the melsure..nt lntervl1 WIS 10*10/15.09=6.6 millisec-
onds. Of course, VIO paging is blocked so the average
OELAY TIME CURVES delay per page-would be less than thilt of i local page-in.
Swap-in delay was 10-18/2.13=85 .illisecands per swap-1n.
RMF MON ITOR I
RMF MONITOR III Paging delay ti ..s can be plotted against the total pag-
ing rate of the systetn frOfl'l .any different MaSurelDent
GATHER OATA ACROSS A RANGE OF intervals. For systells with "all-local" paging config-
LOADS. urations, the total pag1ng rate represents the load
against which the paging resource is requested by each
PLOT RATE VERSUS DELAY. workload component. If swap datasets are present, local
and swap Must be platted separately and against their awn
rates. Example paging delay time curves appear below.
The resource requirements of each worKload component have
been ca 1cu 1ated. However I if the characteri zat i (In
stopped here, they would be somewhat "ou t-of-conuxt li •
There are several major factors that should be understood
that influence resource consumption, and in turn, the
performance of each workload component.
A set of "delay time curves" can be derived which illus-
trate tne relat10nshlp of load versus responsiveness of
two major resources: paging and database. Usin~1 rates
from RMF MOnitor 1 and delays from RMF Monitor IU, these
curves can be plotted.
To calculate resource requirements, only data from peak
load times was used. For the delay time curves, data from
many different times during the day should be used to
insure that a wide range in load is captured.

- BOO •

Find a CMG regional meeting near you at www.cmg.org/regions

 Learn the basics and latest aspects of IT Service Management at CMG's Annual Conference - www.cmg.org/conference

ever, most workload components do not run at the same

dispatching priority, and thus do not necessarily queue
PAGING DELAY TIME CURVES aga1nst the same CPU utilization. A prioritized dis-
patching scheme can be approximated by adjusting the
I utilization in the follOWing manner. A request for exe-

Buy the Latest Conference Proceedings and Find Latest Computer Performance Management 'How To' for All Platforms at www.cmg.org
I cuti on will lIencounter" a CPU ut; 1; za t i on composed of
I higher AND equal priority work; lower priority work will
MI not interfere. From the IPS for the example workload,
SI the relative dispatching priorities placed the workload
I S components in the following order: trivial TSO, non-
oI S trivial TSO, batch. Therefore, the priority scheme for
EI S the example work.load would be: 1) all Ilother" CPU time
l I across all workload components; Z) TCB+SRB time for
AI trlvl.1 TSO; 3) TCB+SRB time for non-trivi.l TSO; 4)
Join over 14,000 peers - subscribe to free CMG publication, MeasureIT(tm), at www.cmg.org/subscribe

YI P TCB+SRB t1me for batch. The CPU utilization resulting

I P from time spent in each of these categories and the re-
I P sulting CPU utilization to queue against for the example
I P V system is given below. Service time is the CPU time per
I V transaction. Each workload component will have two cat-
I V egories of CPU queuing delay; it will queue for its
Ilother'l CPU requ1 rements and for its TCBotSRB require-
ments. The "other" and TCB+SRB CPU time per transaction
TOTAL PAGES/SEC were characterized separately for use in this context.

S = SWAP-IN DELAY
P = PAGE-IN DELAY
V = VIO PAGE-IN DELAY PRIORITY SCHEME
1) ANYBOOY'S "OTHER" CPU TIME
2) TRIVIAL'S TCB+SRB TIME
Database I/O delay time curves cln be gener.ted using 3) NON-TRIVIAL'S TCB+SRB TIME
only RMF Monitor I data. An average response tilH 4) BATCH'S TCB+SRB TIME
weighted by activity rate can be calculated from the DI-
RECT ACCESS DEVICE ACTIVITY REPORT. Plotting thi, tim.
against the total database 1/0 rate produces the curve. TIME %CPU SERVER%
The delay time curves allow the resource requirements of OTHER 2379.5 33.0 33.0
the workload components to be placed "1n-context'~ with TRIV T+S 335.B 4,7 37.7
the ability of the system to deliver the resource in a ·TRIV T+S 1337.7 18.6 56.3
responsive fashton. The sensitivities of I co.ponent to BATCH T+S 971.4 13.5 69.B
fluctuations in load Cln be understood.
SERV TIME (ST) = CPU TIME / TRANS
CPU QUEUING QUEUE TIME = F(#SERVERS,SERVER%) • ST

ANALYTIC MULTISERVER
QUEUING FORMULA A .ultiserver queuing formula can be obtained from any
queuing theory text. In this manner. the sensitivities
of the CPU requirements of each component and their re-
APPROXIMATE PRIORITY lationships to .ach other can be understood.
DISPATCHING BY QUEUING FOR
SERVER UTILIZATION FROM
WORK >= PRIORITY OF WORKLOAD
COMPONENT. SUMMARY

TWO CATEGORIES OF QUEUING Th1s completes the example workload characterization.

FOR EACH WORKLOAD COMPONENT The process may be applied to characterize an installa-
tionls workload using easily obtained data (RMF MONITOR
- QUEUE FOR ·OTHER" CPU TIME I,ll and III reports) and a few hours of hand calcu-
- QUEUE FOR TCB+SRB CPU TIME 1.tions. The purpose of such an eKercise 1s to become
familiar with the data, techniques and assumptions used
for workload characterization. Once this familiarity has
been re.lized. the ability to choose/develop/understand
Another major influencing factor on the abil1ty d I 1I.
tools that utomaticallyll characterize workloads 15 Much
workload component to consume resource is CPU queuing enhlnced.
delay - when « transaction needs the CPU, how long does
it have to wait to be dispatched? This effect Cln be Workload characterizations can provide a great deal of
estimated using the characterized CPU time per trans- insight into the performance sensitivities of the compo·
action and analytical queuing fo~ulas. nents of a workload. Work.ing with the dati to identify
the resource requirements and the factors which influence
A multi server analytical queuing fonmula is a function the ability to consume the resources can estab'1sh a
of three factors: number of servers, server utilization foundation on which tuning and capacity planning can be
and service time. The number of servers is simply the bl ..d.
number of CPUs that make up the the system. The server
utiliZition is the CPU utilization of the systelrl. How-

. eo, .
Find a CMG regional meeting near you at www.cmg.org/regions