There are a wide variety of tools available to measure the performance of your operating system, some of which are included in VSE Tools, and VM Tools. When you look for performance measurements in those tools, focus on three questions. How well is the system performing as a whole? How well is your database machine or partition performing? How is the database machine or partition affecting the performance of other processes that are running at the same time? With that in mind, consider the following generic measurements:
Measure the overall percent utilization of your processor (CPU), refer to Processor. You also need to measure the percentage of the total CPU time devoted to the database machine or partition, refer to Concurrency.
Measure the number of virtual pages in your database machine or partition that have been allocated real storage. Break the real pages into main, and auxiliary pages (and in the case of VM, expanded storage pages). Refer to Real and Virtual Storage. Also compare the number of virtual pages that have been allocated above the 16MB line to those below, refer to Storage Above 16MB (31 Bit Addressing).
Measure the rate of DASD I/O to and from auxiliary storage, refer to Auxiliary Storage. Pay special attention to I/O to and from system paging DASD. This is the slowest type of auxiliary storage and the largest drain on performance. Also, compare the overall system paging DASD load to that required by the database machine or partition.
Measure the rate of DASD I/O initiated by the database machine or the partition itself, refer to Database I/O. The database manager directs the operating system to write and read pages to and from its data, directory, log, and archive disks or datasets. These I/Os are independent of system paging DASD and are always measured separately.
This includes individual DASD volumes, channels, and controllers. Measure the percentage of time that these individual devices are busy. This is more effective than using a load measurement because it takes into account the capability of the device itself. Refer to DASD Balancing.
The following is a description of the CP INDICATE USER and QUERY TIME commands included with the VM operating systems. It serves as an example of how to extract performance counters and simple measurements and translate them into useful indicators.
These two commands enables you to monitor the overall performance of your database machine. The most important indicators they provide are:
| Note: | Several IUCV *BLOCKIO requests may be blocked together to form a single IO request. This count includes all the IO requests, it does not count each page or block moved. |
The IO value will not equal the DASDIO counter.
These commands are only really useful when you use them together. To issue QUERY TIME and INDICATE USER together, type the following from the operator console:
#CP QUERY TIME #CP INDICATE USER
| Note: | The # symbol is the default escape character. It may be different depending on how your system has been customized. |
You also need to compare two consecutive commands. For example, consider the following two QUERY TIME and INDICATE USER commands:
+--------------------------------------------------------------------------------+ |#cp query time #cp indicate user | |CP QUERY TIME | |CP INDICATE USER | |TIME IS 15:07:20 EST TUESDAY 02/14/99 | |CONNECT= 01:21:45 VIRTCPU= 000:06.28 TOTCPU= 000:09.86 | |USERID=SQLDBA MACH=XC STOR=0009M VIRT=V XSTORE=NONE | |IPLSYS=CMS DEVNUM=00031 | |PAGES: RES=001497 WS=001260 LOCK=000000 RESVD=000000 | |NPREF=000000 PREF=000000 READS=000130 WRITES=000018 | |CPU 00: CTIME=01:22 VTIME=000:06 TTIME=000:10 IO=007553 | | RDR=000000 PRT=000738 PCH=000000 | | VVECTIME=000:00 TVECTIME=000:00 | | | |#cp query time #cp indicate user | |CP QUERY TIME | |CP INDICATE USER | |TIME IS 15:08:31 EST TUESDAY 02/14/99 | |CONNECT= 01:22:56 VIRTCPU= 000:07.50 TOTCPU= 000:11.82 | |USERID=SQLDBA MACH=XC STOR=0009M VIRT=V XSTORE=NONE | |IPLSYS=CMS DEVNUM=00031 | |PAGES: RES=001499 WS=001472 LOCK=000000 RESVD=000000 | |NPREF=000000 PREF=000000 READS=000135 WRITES=000022 | |CPU 00: CTIME=01:23 VTIME=000:08 TTIME=000:12 IO=009049 | | RDR=000000 PRT=000974 PCH=000000 | | VVECTIME=000:00 TVECTIME=000:00 | +--------------------------------------------------------------------------------+
The output shows that, during 71 seconds (CONNECT advanced from 01:21:45 to 01:22:56) the following occurred:
There are four important values that you can calculate from these numbers:
For example, from the previous example:
For more information, refer to the VM/ESA: CP Command and Utility Reference manual.
This facility collects performance data during on-line processing for later off-line analysis. Monitoring data is recorded in the CICS journal data sets. This data can be formatted using the CICS Performance Analysis Reporting System (CICSPARS) field-developed program. The CICSPARS program is used with the VSE system for generalized performance analysis reporting (DOS/GPAR) to print analysis reports and summary reports of DB2 Server for VSE data as user clocks and counters.
CICSPARS collects performance class data for two general areas, link usage and call usage:
The CICS monitoring facility automatically associates all performance class data with the CICS transaction running at the time. This allows data reduction programs that process this information to construct a performance profile for any given transaction or call summarized by transaction type. With reference to the DB2 Server for VSE timings listed previously, the transaction profile shown in Figure 1 can be created.
Figure 1. CICS Transaction Time Usage
In Figure 1, blocks (A) and (B) represent intervals during the lifetime of the transaction when other services within the CICS environment are being used. Because most of these other services are also represented in the performance class data, the use of these services can also be broken down, if required, in a manner similar to the breakdown shown for the database manager. Consequently, the database manager is integrated into a composite picture of each transaction's performance. This allows any transaction (or set of transactions) experiencing unacceptable response times to be investigated in a simple, systematic manner.
Before the CICS monitoring facility can be run, CICS must be set up to process the clocks and counters to be used and the journals used to record the data. For information on the entries required in various CICS tables, see the DB2 Server for VSE Program Directory.
After the CICS tables have been updated, the CICS monitoring facility can be started by using either the CICS CSTT transaction or the MONITOR=PER keyword of the CICS DFHSIT macro. These methods are also shown in the DB2 Server for VSE Program Directory.
Table 1 shows how to relate the DB2 Server for VSE clocks to the
DFHMCT entries. The specification of the keyword ID maps to the clock
definition. The specifications of the ID keyword must use the numeric
values shown in Table 1.
Table 1. Relationship of CICS DFHMCT ID Keywords to Clocks
| ID Keyword for CICS/VSE DFHMCT Entry | Defines the Clock that Measures |
|---|---|
|
ID=(PP,16) ID=(PP,17) |
Time waiting for a link |
|
ID=(PP,18) ID=(PP,19) |
Time holding a link |
|
ID=(PP,20) ID=(PP,21) |
Time for DB2 Server for VSE processing
|
The CICS DFHMCT entries also define the four DB2 Server for VSE counters. The argument for the ID keyword for these counters must be ID=(PP,22). The order of the four counters is: