We must consider two different applications:
Trend monitoring (= long-term monitoring) for obtaining data for system planning
Bottleneck analysis for locating and eliminating performance problems
The type of monitored data acquisition (frequency, scope) must be adapted to the application.
Trend monitoring
The utilization data of the following resources is required in order to carry out long-term system planning:
CPUs
channels
devices
main memory
Additional monitoring routines need not be activated.
It is advisable to use the following settings for monitoring periods:
Sampling cycle (SAMPLING-PERIOD): | 1000 milliseconds |
Monitoring cycle (OFFLINE-PERIOD): | 5 minutes |
Analysis subinterval | 1 hour |
The monitoring period should cover the entire period from SYSTEM READY through to SHUTDOWN. If output of the online screen report takes too long during the session, you can shorten the online monitoring cycle.
Monitoring times are set using the MODIFY-MEASUREMENT-PERIODS statement.
It is a good idea to create a new SM2 output file every day (OPEN-LOG-FILE / CLOSE-LOG-FILE statements). The SM2U1 routine can be used to combine (and split) daily SM2 output files to create one large file, known as the master SM2 output file. The daily SM2 output files must be added to the master SM2 output file in chronological order.
Bottleneck analysis
Before monitoring is started, you must clarify any performance problems, i.e. performance expectations that are not satisfied. The following problems may exist:
System-oriented performance problems
These arise if the system throughput rate is unsatisfactory, and are indicated by a low transaction rate and/or throughput rate. The most likely cause is the overloading of one or more resources.User-oriented performance problems
These occur due to long delays when handling specific load requirements.
The following monitored variables should be used to analyze bottlenecks. openSM2 also allows for more extensive analysis through addition monitoring programs.
These monitored variables and monitoring programs make it easier to locate overloaded resources:
Monitored variable | Monitoring program |
Number of tasks in the system queues and at devices | Monitored by default |
Number of input/output operations per device | Monitored by default |
Working set per category | Monitored by default |
CPU utilization and number of input/output operations per category | SYSTEM |
Number of input/output operations and volume of data transferred per channel | CHANNEL-IO |
Access to catalog entries | CMS |
Number of transactions | RESPONSETIME, BCAM-CONNECTION and UTM |
The following settings are recommended for monitoring times (MODIFY-MEASUREMENT-PERIODS statement):
Sampling cycle (SAMPLING PERIOD): | 400 milliseconds |
Monitoring cycle (OFFLINE-PERIOD): | 60 seconds |
Analysis subinterval: | 1 – 5 minutes |
Monitoring period: | 0.5 – 5 hours |
Monitoring must be carried out during peak load periods.
Due to the shorter monitoring cycle and the activated monitoring programs, bottleneck analysis produces a large volume of data compared to trend monitoring. The volume of data corresponds to the number of objects monitored. The resulting SM2 output file may be very large.
Because of the volume of data generated, it does not make sense to copy all data record types into the master SM2 output file. SM2U1 can be used to suppress certain data records when updating the master SM2 output file.
To investigate delays when handling special load requirements, you will need further information in addition to the system utilization data described above. To begin with, the monitoring program PERIODIC-TASK or TASK can be used to select a task. The DISK-FILE monitoring program can be used for overloaded disks to determine the files accessed most frequently. It is not possible to list general guidelines for the additional selection of monitoring programs. For further information, please refer to the “Performance Handbook” [5].